[Python-Dev] Status of thread cancellation

[Greg Ewing]

Nick Maclaren wrote:

> Think of updating a complex object in a multi-file database, for
> example.  Interrupting half-way through leaves the database in a
> mess, but blocking interrupts while (possibly remote) file updates
> complete is asking for a hang.

Currently, threads can't be interrupted at all, so
by this argument, the status quo is that we're always
asking for a hang.

My (possibly naive) thought would be

   with interrupts disabled:
     begin transaction
     try:
       with interrupts enabled:
         do the transaction
     except Interrupt:
       roll back the transaction
       raise
     else:
       commit the transaction

Generally, I would approach things by having interrupts
disabled in the top layers of the thread, and enabling
them explicitly in regions where I'm prepared to handle
them. So I'd be happy if they were disabled by default
in a new thread.

I'm not convinced by the argument that kernel programming
is somehow different from application programming in this
area. Seems to me they're both dealing with the same
problem -- concurrent interacting processes and trying
to make sure nothing can get irretrievably jammed up.
So I can't see why similar techiques can't be used to
solve the problems.

> Sockets, terminals etc. are stateful devices, and killing a process
> can leave them in a very unclean state.

I agree that ttys are far too stateful -- if I were
designing an OS I'd do them differently (more like
STREAMS with pluggable layers). But I've never noticed
any problem with statefulness of sockets. Maybe I don't
use them in a fancy enough way.

> the X focus being left in a stuck override redirect window
> and so on.

That's a misfeature of X, IMO -- it shouldn't be possible
for a client to grab the entire display, only the windows
that it owns. And there should always be a way of forcibly
killing a client using nothing but the X server itself.

--
Greg