How to force a thread to stop

Steve Holden steve at holdenweb.com
Mon Jul 24 17:03:49 EDT 2006


Carl J. Van Arsdall wrote:
> Jean-Paul Calderone wrote:
[...]
>>This has been discussed many many times in the context of many many
>>languages and threading libraries.  If you're really interested, do
>>the investigation Steve suggested.  You'll find plenty of material.
>>  
> 
> 
> I've been digging around with Queue.Queue and have yet to come across 
> any solution to this problem.  Queue.Queue just offers a pretty package 
> for passing around data, it doesn't solve the "polling" problem.  I 
> wonder why malloc()'s can't be done in an atomic state (along with other 
> operations that should be atomic, maybe that's a question for OS guys, I 
> dunno).  Using Queue.Queue still puts me in a horribly inflexible 
> "polling" scenario.  Yea, I understand many of the reasons why we don't 
> have "threadicide", and why it was even removed from java.  What I don't 
> understand is why we can't come up with something a bit better.  Why 
> couldn't a thread relinquish control when its safe to do so?  While the 
> interpreter is busy doing malloc()s a thread receives a control message, 
> the thread waits until it knows its no longer in an atomic state and 
> gives control to the message handler when it can.  Its about setting up 
> a large system that is controllable without the painstaking process of 
> putting message polling loops all over the place.  Main threads in a 
> python program can setup a signal handler, accept signals, and that 
> signal can happily go ahead and kill a python interpreter.  Why can't 
> this concept be taken farther and introduced into threading? 
> 
I take this to mean you don't want to do the necessary research? ;-)

> There is no system that is completely interruptible, there will always 
> be a state in which it is not safe to interrupt, but many systems work 
> around this just fine with cautious programming.  Has anyone considered 
> an event driven approach to sending control messages to threads?
> 
The big problem (as you'll see when you ...) is providing facilities 
that are platform-independent.

regards
  Steve
-- 
Steve Holden       +44 150 684 7255  +1 800 494 3119
Holden Web LLC/Ltd          http://www.holdenweb.com
Skype: holdenweb       http://holdenweb.blogspot.com
Recent Ramblings     http://del.icio.us/steve.holden




More information about the Python-list mailing list