Cancelling a python thread (revisited...)

[John Nagle]

Carl Banks wrote:
> Arguing that there are good reasons to allow killing threads isn't
> going to get you very far.  The language developers already know
> killing a thread is useful, yet the disallowed it anyway.  The
> drawbacks were judged too severe (it makes enforcing invariants pretty
> much impossible).

    While outright thread cancellation is generally unsafe, it would
be useful if there was a way to force another thread to unblock from
a wait condition, like a blocking read, with an exception.  This is,
among other things, why control-C won't terminate some threaded programs.

    Python 2.6 and 3 have some steps in this direction.  There's
"signal.set_wakeup_fd(fd)", and "siginterrupt()". But the real
problem, that signals are associated only with the first thread, hasn't
been addressed.

    Question: if "signal.set_wakeup_fd(fd)" is used, and the thread
waiting on "fd" is not the main thread, will a signal cause the
waiting thread to get a read completion?  Or is this another "first
thread only" thing"?

				John Nagle