bug-gnulib
[Top][All Lists]
Advanced

[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
> 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.




reply via email to

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