threading: how to kill a (possibly blocked) thread?

[David Bolen]

George Young <gry at ll.mit.edu> writes:

> Is there a way to get a 'thread' reference from my Threading object
> and call it's exit function?  Will this confuse Threading and break
> other things?

Unless the exit() is called from within the thread itself, it won't
terminate the thread, and no, I'm not aware of any way to externally
terminate a Python thread - at least not cleanly or in a supported manner.

Terminating a thread externally (from another thread) is not something
supported in most threading systems/OSs.  Those that have had some
mechanism have, I believe, had trouble ensuring proper behavior.  Most
systems recover resources at the process level, so cleanup on a
per-thread basis is not reliable.

What you really need to do is ensure that your threads can accept an
external request to terminate themselves, and then code the threads
defensively to ensure they check for such requests at some periodic
interval.  It's not always the simplest approach, but it's one of the
fairly standard consequences of threaded development.

Python threads are pretty nice in that your class representing your
thread can provide some extra methods that are actually intended to be
called from some other thread in order to set the signaling, avoiding
some of the global flag objects that tend to get used in other
threading environments.

For example, when your thread starts up, it can create an event object
in the reset state and store it within the object instance.  It could
then provide a method that a main application thread could call to
request the thread to exit which in turn would set that internal event
object.  The method is running within the context of the main
application thread, but accessing shared instance data which will then
be checked by the separate thread running that object.  The main
thread code should then check the event object periodically and exit
nicely if it is set.

This does mean that you have to keep the thread from blocking
indefinitely.  It doesn't mean you can't block at all, depending on
how much latency you are willing to put up with should you wish to
exit, or if the blocking is related to multi-thread interaction.  For
example, if you know that you may be blocked in an acquire() call,
your design may assure you of eventually getting control back as the
other threads begin to terminate (and given that at least one thread
must have the lock, and presumably is checking its exit flag while not
blocked).  With I/O, you should operate in a non-blocking or
interruptible mode (using select() for sockets, or files under Unix,
etc...) where you can get a periodic chance to check for the
termination request.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/