Killing threads

[Dave Brueck]

> >> 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.

Depending on your OS it still probably means an extra pair of kernel calls
for each Queue access. To me, in that particular case, it was worth it. To
you, it wasn't. No big deal.

> >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.

Semaphores... and they are so simple to use I'd hardly consider it
"mucking".

> 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!  ;-)

Huh? The poll isn't during the wait-for-work part of the class. This is a
polling loop during Stop(), when you're shutting down (most likely
destroying) the work queue, and is there to ensure a clean shutdown. The
sleep() call usually happens 0 or 1 times and no more. I too am a big
believer in simple (and intuitive code).

Using a queue (vs. sleep) there would arguably be bad for two reasons:
1 - it is NOT more efficient to use a queue (create/wait/signal/destroy a
queue vs. 0 or 1 sleep calls). Even if avoiding sleep() _was_ more
efficient, who cares? You're essentially optimizing a function that normally
is called once in the entire lifetime of a WorkQueue. For that matter,
there's plenty of other useless micro-optimizations to do as well.

2 (** much more important **) - it would NOT make the code simpler - you're
calling Stop to shutdown the worker thread so you set its flag to signal the
"stop working" state, wait a little for it to respond, and move on. Not only
is the sleep method simpler, it is more intuitive (or maybe I'm not seeing
your point.. can you elaborate on how using a queue is a simpler and/or more
intuitive approach?).

> I'm also not a big fan of dispatching threads on functions/methods.
> It's almost always clearer to just subclass from threading.Thread.

That's ok, I wasn't starting a fan club <0.6 wink> (to me it is at best
equally clear to subclass threading.Thread, and less so in this case).

-Dave