Thread interrupt revisited (was Re: try: finally: question)

[Peter Hansen]

Antoon Pardon wrote:

> Sure, but lets look at the problem of not allowing one
> thread to pause, interrupt or raise an exception in
> an other thread. The defense for not allowing these
> things has been that they would introduce suble bugs.

Actually, I think it's only interrupting that's been
discussed, and the main issues are (a) what to do if
the thread is blocked in an external (extension) call,
and (b) if the answer to (a) is "nuke the thread anyway!"
then what to do about cleanup.

Pausing shouldn't be an issue, though I'm not sure I
know any decent usecase for it.  Raising an exception
should be pretty straightforward, and I have sneaking
suspicion (actually, it's a memory, and probably a wrong
one!) that that's how it's done in the addition that was
made to the core recently via a call in an extension
(Google Groups would bring up a message from Alex Martelli
describing it, I believe, or was it Aahz?).

> If one thread could raise an exception in an other
> one, this could be far easier.

Anyone interested should try to dig up that past reference
to an addition that was made to allow killing threads.
I ought to remember whether it raised an exception, but
I don't.  I agree that would probably be the best way
to handle it, but a lot of people who insist they need
thread killing will probably be disappointed if it can't
kill a thread that is caught in an external routine, or
if it can kill such threads, they will end up writing
code that is buggy because it doesn't clean things up
properly... oh well.

> But IMO it could go further. One program can signal an other.
> That is an old practice that still is around. So why not
> allow one thread to "signal" an other.

Sounds easy to say, but what does it mean?  What actually
happens in the thread that is signalled?  How does it process
the signal if it's blocked, say in a socket.accept() call,
for two minutes?