Dennis Lee Bieber wrote:
> On Sat, 22 Jul 2006 14:47:30 +0200, "Hans" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED]
Build and Release
MontaVista Software
--
http://mail.python.org/mailman/listinfo/python-list
