How to force a thread to stop

[bryanjugglercryptographer at yahoo.com]

Carl J. Van Arsdall wrote:
[...]
> 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.

A polliing loop is neither required nor helpful here.

[...]
> #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')

What good do you think killing that thread would do? The
process running 'op n' has no particular binding to the thread
that called os.system(). If 'op n' hangs, it stays hung.

The problem here is that os.system doesn't give you enough
control. It doesn't have a timeout and doesn't give you a
process ID or handle to the spawned process.

Running os.system() in multiple threads strikes me as
kind of whacked. Won't they all compete to read and write
stdin/stdout simultaneously?

> #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()

Nonsense. If op() hangs, you never get to checkMessageQueue().

Now suppose op has a timeout. We could write

  def opcheck(thing):
      result = op(thing)
      if result == there_was_a_timeout:
          raise some_timeout_exception

How is:

  def func_to_thread():
      opcheck('op 1')
      opcheck('op 2')
      opcheck('op 3')

any less managable than your version of func_to_thread?

> 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?

Threadicide would not solve the problems you actually have, and it
tends to create other problems. What is the condition that makes
you want to kill the thread? Make the victim thread respond to that
condition itself.


-- 
--Bryan