[issue12187] subprocess.wait() with a timeout uses polling on POSIX

[Charles-François Natali]

Charles-François Natali <neologix at 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 <report at bugs.python.org>
<http://bugs.python.org/issue12187>
_______________________________________