waiting on an event blocks all signals

[Rhamphoryncus]

On May 18, 9:05 am, "Diez B. Roggisch" <de... at nospam.web.de> wrote:
> alan schrieb:
>
> > This ignores CTRL-C on every platform I've tested:
>
> > python -c "import threading; threading.Event().wait()"
> > ^C^C^C^C
>
> > It looks to me like all signals are masked before entering wait(). Can
> > someone familiar with the internals explain and/or justify this
> > behavior? Thanks,
>
> They aren't masked. Read the docs:
>
> # Although Python signal handlers are called asynchronously as far as
> the Python user is concerned, they can only occur between the ``atomic''
> instructions of the Python interpreter. This means that signals arriving
> during long calculations implemented purely in C (such as regular
> expression matches on large bodies of text) may be delayed for an
> arbitrary amount of time.
>
> (http://docs.python.org/lib/module-signal.html)
>
> Which is what is happening here - wait is implemented in C. So the
> arriving signal is stored flagged in the interpreter so that the next
> bytecode would be the signal-handler set - but the interpreter still
> waits for the blocked call.

If a signal arrives while the thread is in a syscall it will usually
interrupt the syscall.  Most code in the interpreter will see the
EINTR error code and check if we have a signal to process, which leads
to raising a KeyboardInterrupt exception.  However, most thread
synchronization functions specified in POSIX are not interrupted by
signals, so the interpreter never has a chance do anything.  Why would
we care anyway, as Python doesn't let you intentionally interrupt a
non-main thread?