How to force a thread to stop

[Carl J. Van Arsdall]

Jean-Paul Calderone wrote:
> On Mon, 24 Jul 2006 11:22:49 -0700, "Carl J. Van Arsdall" <cvanarsdall at mvista.com> wrote:
>   
>> Steve Holden wrote:
>>     
>>> Carl J. Van Arsdall wrote:
>>> [... rant ...]
>>>
>>>       
>>>> So with this whole "hey mr. nice thread, please die for me" concept gets
>>>> ugly quickly in complex situations and doesn't scale well at all.
>>>> Furthermore, say you have a complex systems where users can write
>>>> pluggable modules.  IF a module gets stuck inside of some screwed up
>>>> loop and is unable to poll for messages there's no way to kill the
>>>> module without killing the whole system.  Any of you guys thought of a
>>>> way around this scenario?
>>>>
>>>>
>>>>
>>>>         
>>> Communications through Queue.Queue objects can help. But if you research
>>> the history of this design decision in the language you should discover
>>> there are fairly sound rasons for not allowing arbitrary "threadicide".
>>>
>>>
>>>
>>>       
>> Right, I'm wondering if there was a way to make an interrupt driven
>> communication mechanism for threads?  Example: thread receives a
>> message, stops everything, and processes the message.
>>
>>     
>
> And what happens if the thread was halfway through a malloc call and
> the data structures used to manage the state of the heap are in an
> inconsistent state when the interrupt occurs?
>
> 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? 

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?

-c

 





-- 

Carl J. Van Arsdall
cvanarsdall at mvista.com
Build and Release
MontaVista Software