Idle wait for outstanding threads?

[Alan Kennedy]

"Alex Martelli" <aleax at aleax.it> wrote:

> I see several other have already recommended Python standard module Queue,
> and I heartily second the recommendation.  Many useful multithreaded
> architectures can be put together most simply with Queue as the only
> synchronization mechanism.

Indeed, I have decided to go with a Queue.Queue solution, involving a
pre-created pool of worker threads. It makes things so much easier.
The many advantages include

1. No thread creation overhead. (See below).
2. Simpler code (which is of course much more likely to operate
*correctly*)
3. Prevents the possibility of inadvertently creating too many
threads, i.e. more threads than the OS will allow at once.

> But for your problem as you outline it elsewhere, timeouts don't
> seem strictly necessary.  You could have 4 dedicated working threads
> each waiting on a separate Queue instance; when a work-request
> arrives on the working thread's Queue, the thread does the work,
> posts the result-description to a single results-Queue (common to
> all working threads), and loops back to waiting.  The main thread,
> when a request arrives, slices it up into work-requests, posts each
> to the appropriate working thread's Queue, then goes pluck the N
> expected result-descriptions from the single results-Queue, collates
> overall results, and responds to the request.

I still think the timeout is required. The actual work being done is
database queries, which can fail for a number of reasons, or possibly
take an excessively long period of time. I need to catch those
situations and deal with them explicitly, rather than have requests
hang, while they are waiting for query results that are never going to
arrive, or take an inordinately long time.

> You probably don't want to incur the overhead of starting and
> terminating N working threads per request; the above-sketched
> "thread-pool" approach is generally more effective.  

After doing some quick timings of thread creation and
destruction/collection/joining/(?) I decided that the overhead wasn't
worth it. On my 1.2 Ghz Athlon, creation and destruction of a thread
took 400 µ-secs. Not huge, but when multiplied by 5 or 10 threads, it
starts to look significant.

> Couldn't some architecture patterned on this example satisfy
> your needs?

Indeed it can, as described above.

Thanks for the assistance.

Regards,

Alan.