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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4