[Python-Dev] POSIX thread code

[Tim Peters]

[Tim]
> I'm deadly opposed to letting a keyboard interrupt break out of a
> wait for a Python lock.

[Guido]
> 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.