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]

Re: waiting on an event blocks all signals

On Sat, May 17, 2008 at 2:49 PM, John Schroeder <jschroed@gmail .comwrote:

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

>>
>python -c "import threading; threading.Event ().wait()"
>^C^C^C^C

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

[Diez B. Roggisch]

Re: waiting on an event blocks all signals

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.

Diez

[Rhamphoryncus]

Re: waiting on an event blocks all signals

On May 18, 9:05 am, "Diez B. Roggisch" <de...@nospam.w eb.dewrote:

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 KeyboardInterru pt 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?