I was trying to avoid taking sides on the keyboard interrupt issue. I do prefer only having to type ^C once, but Python doesn't always do that now (at least not on my platforms), and there are certainly issues trying to do it portably. I wouldn't want to be involved in that effort. The point of the quote was to show that Mutexes/Condition variables have (or at least can have) the same behavior wrt interrupts as this: do { status = sem_wait(lock); } while ((status == -1) && (errno == EINTR)); So we can treat keyboard interrupts as a separate issue. -Jerry -O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O- Tim Peters wrote:
I'm deadly opposed to letting a keyboard interrupt break out of a wait for a Python lock. [...]
If a signal is delivered to a thread waiting for a mutex, upon return from the signal handler the thread shall resume waiting for the mutex as if it was not interrupted. and: If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread shall resume waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup.
Sorry, I don't grasp what the point of this quoting was, unless it was a roundabout way of merely confirming that keyboard interrupts can't break out of a wait for a Python lock today (which was known and said before).