Killing threads

[ericwoodworth at gmail.com]

On Apr 6, 3:45 am, bieff... at gmail.com wrote:
> On 6 Apr, 05:25, ericwoodwo... at gmail.com wrote:
>
>
>
> > On Apr 5, 11:07 pm, Dennis Lee Bieber <wlfr... at ix.netcom.com> wrote:
>
> > > On Sun, 5 Apr 2009 17:27:15 -0700 (PDT), imageguy
> > > <imageguy1... at gmail.com> declaimed the following in
> > > gmane.comp.python.general:
>
> > > > In threading.Event python 2.5 docs say;
> > > > "This is one of the simplest mechanisms for communication between
> > > > threads: one thread signals an event and other threads wait for it. "
>
> > > > Again, I have limited experience, however, in my reading of the
> > > > threading manual and review examples, Events were specifically design
> > > > to be a thread safe way to communicate a 'state' to running threads ?
> > > > In the OP's example 'do stuff' was open to wide interpretation,
> > > > however, if within the thread's main 'while' loop the tread checks to
> > > > see if the 'keepgoing' Event.isSet(), in what scenario would this
> > > > create deadlock ?
>
> > >         If you are going to perform a CPU intensive polling loop, there is
> > > no sense in using the Event system in the first place... Just create a
> > > globally accessible flag and set it to true when you want to signal the
> > > threads (or false if you don't want to use the negation "while not
> > > flagged: do next processing step")
>
> > >         Event is optimized for the case wherein threads can WAIT (block) on
> > > the Event object.
> > > --
> > >         Wulfraed        Dennis Lee Bieber               KD6MOG
> > >         wlfr... at ix.netcom.com             wulfr... at bestiaria.com
> > >                 HTTP://wlfraed.home.netcom.com/
> > >         (Bestiaria Support Staff:               web-a... at bestiaria.com)
> > >                 HTTP://www.bestiaria.com/
>
> > Well it turns out my problem was with queues not with threads.  I had
> > a self.die prop in my thread object that defaults to FALSE and that I
> > set to true when i wanted the thread to die.  then my loop would be
> > while not die:  It seemed pretty simple so I didn't know why it was
> > failing.  What I didn't know, because I'm quite new to python, is that
> > queue.get was blocking.  So my producer thread why dying immediately
> > but my worker threads were all blocking on their queue.gets.  So they
> > were never falling off the loop.  I changed it to queue.get_nowait()
> > and added a queue.empty exception and everything worked as expected.
>
> > So I thought I knew what was going on and that I was having a really
> > esoteric problem when i was actually having a pretty boring problem I
> > didn't recognize.
>
> > Thanks everybody for the help!>
>
> I've gone through that also, when I started with python threads :-)
> Be aware that using get_nowait may lead to your thread using too much
> CPU in checking a queue often empty. I tend to use  Queue.get with a
> timeout, smaller enough to keep the thread responsive but large enough
> not
> to waste CPU in too-frequent checks.
>
> Ciao
> -----
> FB

Ok thanks - good to now.  I'm trying to throttle it with a 1/2 sec
sleep statement in the loop but I might just have the "main" loop toss
some stuff on that queue as another solution.  I'm still kicking it
around