Killing threads

[Aahz Maruch]

In article <mailman.985014274.27176.python-list at python.org>,
Dave Brueck <dbrueck at edgix.com> wrote:
>Aahz:
>>
>> I'm confused.  Is there some reason you're not using Queue.Queue()?
>
>Queue is overkill for simple one-to-one workflows - it's built to be
>multi-consumer and multi-producer so every get/put/check requires acquiring
>and releasing the Queue's mutex (granted, in most cases that probably won't
>make too big of a different, but...).

That's partly true; there are still single producer/consumer cases where
you need a mutex.  The only reason you can get away with it in Python is
because the GIL (global interpreter lock) does a lot of the work for
you.  The flip side is that the GIL means a mutex really adds little
overhead in the single producer/consumer case.

>Anyway, the point here is killing separate threads and my WorkQueue class
>was that was the first example that came to mind. Note that whether or not
>you use Queue.Queue makes little difference in solving this problem:

Not overall, no, but it does mean you don't have to muck with mutexes.
I'm a big believer in simple code.  One problem with the code you posted
is that it has a polling loop (with time.sleep()) in it; that's not good
for efficiency.  Use another queue!  ;-)

I'm also not a big fan of dispatching threads on functions/methods.
It's almost always clearer to just subclass from threading.Thread.
-- 
                      --- Aahz  <*>  (Copyright 2001 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het Pythonista   http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

There's a difference between a person who gets shit zie doesn't deserve
and a person who gets more shit than zie deserves.  --Aahz