[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[Antoine Pitrou]

Antoine Pitrou <pitrou at free.fr> added the comment:

>  1. On FreeBSD, we must assume that every blocking system call, in *every thread*, can be interrupted, and we need to catch EINTR.
> 
>  2. On FreeBSD, we cannot block indefinitely in the main thread and expect to handle signals. This means that indefinite selects are not possible if we want to handle signals, and, perhaps more perversely, signal.pause() cannot be reliably used in the main thread.

Well, I agree it makes matters more complicated, but if FreeBSD decides this behaviour is desireable, why would Python try to work around it?
To solve the select() problem you can have the signal handler write on a pipe (using signal.set_wakeup_fd (*)) and the select() call wait on that pipe. This also should allow to emulate signal.pause() (basically a select() with only the signal pipe).

IMHO, the general idea of Unix signals is a low-level kludge and any attempt to make it sane at the Python level is probably doomed to failure. Other synchronization methods should always be preferred, if possible.

(*) Linux has signalfd, but we don't expose it yet

----------
nosy: +haypo, neologix
versions: +Python 3.3 -Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________