[Python-Dev] Status of thread cancellation

[Greg Ewing]

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