Charles-François Natali <neolo...@free.fr> added the comment: > Antoine is right: we don't have to be portable.
We don't have to, but writing one POSIX-conformant solution is better than writing N OS-specific solutions, no? That's what POSIX is about. > Should we block the signal? Yes. > What happens when we unblock the signal? If you've read from the FD, nothing, since it consumes the pending signals. If you haven't, since signal_pthread_sigmask checks for pending signals, I guess that the handler will be called upon unblock. But signalfd is designed as an alternative to handlers, so I don't think this makes much sense, and if a SIGCHLD handler is setup, it's likely to perform a waitpid(-1, WNOHANG), which will screw up our waiting anyway... > Is it possible to block a signal in all threads? Not portably. > sigwait() is not impacted by the associated signal handler, but sigwait() > only works if the signal is blocked (e.g. by pthread_sigmask): The point I was making is precisely that blocking the signal is not enough on some kernels: when the signal is ignored, it will sometimes not wakeup threads waiting on sigwait. > sigprocmask(), sigwait() and signals in general seem to behave differently on > each OS They behave correctly as long as they're used in a POSIX-conformant way. To sum up, those problems are: - since SIGCHLD is ignored by default, some kernels won't wake up threads waiting on sigwait (it works on Linux, don't know for *BSD kernels) - there's not portable way to block signals in all threads. As a consequence, there will be cases where sigtimedwait or select on a signalfd will wait until the end of the timeout. > See also issue #8407 for sigtimedwait() and signalfd() in Python. You didn't commit the signalfd part? Whay do you think of sigtimedwait? Expose it as-is, or just add an optional timeout option to sigwait? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12187> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com