Antoine Pitrou <pit...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue1975> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
