[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c

From: Jim Meyering
Subject: Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Date: Sat, 28 Feb 2009 16:16:57 +0100

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]