waiting on an event blocks all signals

[alan]

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,

-Alan

 

[alan grow]

^C only kills the main thread. Use Control-Break to kill all threads.

There's a single main thread here though. Or am I missing something?

 

[Diez B. Roggisch]

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.

Diez

 

[Rhamphoryncus]

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?