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

Greg Ewing greg.ewing at canterbury.ac.nz
Tue Mar 20 00:32:49 CET 2007

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

More information about the Python-Dev mailing list