[Python-Dev] Status of thread cancellation (original) (raw)

Greg Ewing greg.ewing at canterbury.ac.nz
Fri Mar 16 00:27:48 CET 2007

Facundo Batista wrote:

are there processors that support "reentrant" interrupts?

The PDP11 had seven priority levels for interrupts. When an interrupt was handled, interrupts with priorities less than or equal to the current level were blocked, but the handler could be interrupted by a higher priority interrupt.

Also, on any processor I know about, there's nothing to stop an interrupt handler re-enabling interrupts once it's ensured that the particular one it's handling isn't going to happen again. You can use this to implement an interrupt priority scheme in software if the hardware doesn't support it.

So yes, re-entrant interrupts do make sense in some situations.

The thing to model this on, I think, would be the BSD sigmask mechanism, which lets you selectively block certain signals to create a critical section of code. A context manager could be used to make its use easier and less error-prone (i.e. harder to block async exceptions and then forget to unblock them).

But, in that scenario, should be a way to say to the thread "Die, die now, no matter what"?

Unconditionally killing a whole process is no big problem because all the resources it's using get cleaned up by the OS, and the effect on other processes is minimal and well-defined (pipes and sockets get EOF, etc.). But killing a thread can leave the rest of the program in an awkward state.

I'm inclined to think that there should be some way to do it, and any locks held by the killed thread should be broken. It's then up to the program to deal with the consequences. If it's not willing to do that, then it shouldn't use the instant-death mechanism.

-- Greg

More information about the Python-Dev mailing list