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

[Antoon Pardon]

Op 2004-07-08, Peter Hansen schreef <peter at engcorp.com>:
> 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,

Well the few times I saw the discussion coming up I
tried to expand it, but with little succes.

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

Well my first thought would be to send the thread a
signal. This way an extension call could install
a signal handler if it needed to cleanup things.

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

Yes I found something but it seems only available in
extension code.

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

People write buggy code all the time. Even in none threaded
code it might be necessary to cleanup things, and it isn't
done properly because people didn't anticipate a particular
exception being raised.


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

The same that happens in a program that is signaled.
The signalhanler is called.

> How does it process
> the signal if it's blocked, say in a socket.accept() call,
> for two minutes?

Well what happens in a program that gets signalled and
is blocked in a socket.accept() call for two minutes?

Well I went to look at the signal documentation and I must
say I'm a bit annoyed by how signals are handled in python.
As I understand it is impossible to interrupt a python
program by typing ^C, while it is running extension code.
The interruption will occur when the extension code is
done. I think this is a bad idea.

-- 
Antoon Pardon