Threading Pool Event()

[Tim Peters]

[Graeme Matthew]
> ok still a bit confused sorry .... first attempt at a thread pool
>
> Am I correct in saying that each thread runs in a continious loop

That's a usual way to write this, yes.

> each thread calls queue.get.

Right.

> The get method will block and not return anything until an item is
> placed into it.

Until an item is placed into the Queue object, via a Queue.put() call made
in some other thread.

> When an item is placed into it, one of the threads will get assinged a
> job i.e the first one that happens to be in use during the cycle ?

*Some* thread's .get() call will return then.  Nothing is defined about
*which* thread.

> The job is returned to the thread, it runs with the job and does all
> the processing then returns and calls queue.get again and waits for a
> job to become available ?

Right.

> When placing a job via Queue.put() one must acquire a lock place it
> and then release it

No.  Work is put on the Queue by calling Queue.put(), and removed from the
Queue by calling Queue.get().  There is no need for you to do any locking;
all necessary synchronization is performed for you, by the methods of the
Queue class.

> Am i aslo correct in saying that queue is actually doing the blocking

Yes.

> and controls which thread gets the job ?

No -- that's up to the vagaries of your operating system's and/or platform C
library's thread implementation, which Python calls.

> Lastly, sorry for all the questions, surely the CPU usage is the same
> when the queue is waiting for jobs and when the threads are polling
> as theyre all in one process anyway

No, blocking on a Queue.get() consumes no (or essentially no <wink>) CPU
time on reasonable platforms.  Blocking is passive.  Polling is active.  The
Queue class doesn't poll.