On May 18, 9:05 am, "Diez B. Roggisch" <[EMAIL PROTECTED]> 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? -- http://mail.python.org/mailman/listinfo/python-list
