Charles-François Natali <neolo...@free.fr> added the comment: > For subprocess.wait(), we can do something with signals (SIGCHLD and/or > SIGCLD).
There's just one problem: SIGCHLD is ignored by default, which means that sigwait and friends won't return when a child exits. Well, it actually works on recent Linux kernels, but POSIX makes no such guarantee, and it's at least known to fail on Solaris (see Dave Butenhof's comment): http://www.multithreadedprogramming.info/sigwait-ing-for-sigchld To be portable, we would need to set a handler for SIGCHLD, which has the following problems: - you have to do that from the main thread - it impacts every thread - it will make syscalls fail with EINTR - once you've changed SIGCHLD setting, you can't go back to the original semantic (setting it to SIG_IGN again will prevent children from becoming zombies, and waitpid wait until all children exited and will fail with ECHILD) Note that even if it does work, there's a problem in multi-threaded programs, because the signal must be blocked by all the threads... But since we use it with a timeout, we could also consider that this will work on systems that allow ignore signals to be catched by sigtimedwait, and it will wait the full timeout on other systems. I don't know if that's acceptable. > Why not use signalfd() when available? It suffers from the same issue, and it's Linux-specific (sigwait and friends are POSIX). Note that exposing sigtimedwait is probably useful anyway, and I'd like to work on a patch. Note that I'm not sure that exposing sigtimedwait is necessary (I don't think that the info field is going to be used by Python applications): how about just adding an optional timeout argument to signal_sigwait? ---------- nosy: +neologix _______________________________________ 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