I'm deadly opposed to letting a keyboard interrupt break out of a wait for a Python lock.
I've heard this before. Can you explain why?
The code would be a mess, it wouldn't work across platforms (e.g., interrupts are invisible to a wait on a POSIX condvar), and it would change current behavior.
It would not be incorrect -- if the SIGINT had arrived a microsecond before the wait started, the program would have been interrupted in exactly the same state.
Ya, and if my program has been deadlocked for 4 hours, it's exactly the same as if it had simply been swapped out for that long without deadlock, and then the interrupt occurred right before it was about to grab the fatal lock. Try explaining that to a user base that thinks time.sleep() is an advanced synchronization technique <wink>.
It's one of the few places where code can be blocked in a system call (if you want to call a lock wait a system call -- it's close enough for me)
I'd be more upset about that if it weren't the purpose of lock.acquire() to block <wink>. If a user doesn't want to block, they should poll, acquire-with-timeout, or fix their bad assumptions.
and a ^C doesn't stop it, and that can be annoying at times.
Of course, if it's not the main thread, signals including SIGINT shouldn't do anything, but that's a separate issue.
Why should the main thread act differently?
Breaking the main thread IMO is useful behavior for interactive programs and for scripts invoked from the command line.
Being able to interrupt any thread may be useful. I guess I don't see what's especially useful about breaking the main thread. If my program is hosed, I'd just as soon kill the whole thing.
(In practice, this is probably only interesting for interactive use -- if you hang your main thread on a deadlock, there's no way to get your prompt back, and that may mean no way to figure out what went wrong or save stuff you wanted to save.
Hmm. The "save stuff" use may be most valuable for non-interactive long-running jobs, assuming that it's possible to save stuff despite that the rest of your threads remain deadlocked (implying they're all holding some lock). I suppose if you can guess which lock the main thread broke out of, you could at least release that one and hope for some progress ...
I don't know. If the possibility were there, I expect one could, with care, rely on its details to build some more-or-less useful scheme on top of it -- at least on platforms where it worked. It's really not all that attractive on its own; maybe learning how to build efficient interruptible locks x-platform could lead to a more general gimmick, though.