Bruno Haible wrote: > Jim Meyering wrote: >> [reviving an old thread...] > > This was a reply to > <http://lists.gnu.org/archive/html/bug-coreutils/2008-10/msg00216.html>, > for those who - like me - lost the context after 4 months. > >> I confirmed that running with SIGCHLD ignored, and regardless >> of which wait function it uses (wait, waitpid, or waitid), the >> parent still fails to determine the child's exit status. I.e., >> each of the wait functions does wait, but then returns -1/ECHILD >> rather than the child's PID. > > That's as expected, according to POSIX > (<http://www.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03> > section SIG_IGN). > >> Which makes me think gnulib's wait-process.c will have to be changed >> to deal with this. > > wait-process.c is meant to react depending on the exit code of the child > process. So the change I could apply is to add a comment in the specification: > "This function assumes that the signal handler for SIGCHLD is not set to > SIG_IGN."
Thanks. That's probably all that it can do. Though isn't it better to say it assumes the handler *is* set to SIG_DFL? > Do you have something else in mind? Hadn't investigated. Obviously the set-sig-handler-to-default advice could only be taken by an application, not by the library itself. Though, at the other extreme, wait-process.c could print a diagnostic about the potential portability problem when it sees the SIGCHLD handler is not SIG_DFL. Or return a value indicating the problem -- esp. if it already knows it's running on a system with the losing semantics.
