How to force a thread to stop

Carl J. Van Arsdall cvanarsdall at mvista.com
Mon Jul 24 13:27:08 EDT 2006


Dennis Lee Bieber wrote:
> On Sat, 22 Jul 2006 14:47:30 +0200, "Hans" <NoSpam at Hccnet.nl> declaimed
> the following in comp.lang.python:
>
>   
>> Hi all,
>>
>> Is there a way that the program that created and started a thread also stops 
>> it.
>> (My usage is a time-out).
>>
>>     
> 	Hasn't this subject become a FAQ entry yet? <G>
>
> 	The only reliable way of stopping a thread is from inside the thread
> itself. That is, the thread must, at some point, examine some flag
> variable which, when set, says "stop"
>
> Without using actual code:
>
> class StoppableThread(...):
> 	def __init__(self, ...):
> 		#whatever is needed to initialize as a thread
> 		self.Stop = False
>
> 	def run(self, ...):
> 		while not self.Stop:
> 			#do one cycle of the computation
>
>
>   

My problem with the fact that python doesn't have some type of "thread 
killer" is that again, the only solution involves some type of polling 
loop.  I.e. "if your thread of execution can be written so that it 
periodically checks for a kill condition".  This really sucks, not just 
because polling is a ridiculous practice, but it forces programmers in 
many situations to go through a lengthy process of organizing operations 
into a list.  For, say I have threads that share a bunch of common 
memory (yea, i'm saying this exclusively to get the procses users off my 
back) that executes a series of commands on remote nodes using rsh or 
something.  So if i've constructed my system using threads I need to 
neatly go and dump all operations into some sort of list so that I can 
implement a polling mechanism, i.e.

opList = [op1, op2, op3, op4]
for op in opList:
  checkMessageQueue()
  op()

That works if you can easily create an opList.  If you want good 
response time this can become quite ugly, especially if you have a lot 
going on.  Say I have a function I want to run in a thread:

#Just pretend for the sake of arguement that 'op' actually means 
something and is a lengthy operation
def func_to_thread():
  os.system('op 1')
  os.system('op 2')
  os.system('op 3')


#In order to make this killable with reasonable response time we have to 
organize each of our ops into a function or something equally annoying

op_1():
  os.system('op 1')

op_2():
  os.system('op 2')

op_3():
  os.system('op 3')

opList(op_1, op_2, op_3)
def to_thread():
  for op in opList:
    checkMessageQueue()
    op()


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?


-- 

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




More information about the Python-list mailing list