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

[Jim Meyering]

Eric Blake <address@hidden> wrote:

> According to Eric Blake on 10/10/2008 7:15 AM:
>>> I've wanted to get rid of "signal" uses for ages.
>>> Are you interested in doing it?
>>
>> Yes, I'll tackle this.
>
> Round 2 begins with a question.  src/install.c has the following use of
> signal, needed on the code path that invokes strip(1) as a child process:
>
> #ifdef SIGCHLD
>         /* System V fork+wait does not work if SIGCHLD is ignored.  */
>         signal (SIGCHLD, SIG_DFL);
> #endif
>
> I just checked POSIX, and this is entirely true - the exec*() family is
> allowed to inherit an ignored SIGCHLD, in deference to older systems like
> SysV; and wait()/waitpid() are allowed to fail with ECHILD if SIGCHLD is
> ignored.  But most systems these days explicitly set SIGCHLD to SIG_DFL on
> fork; are there still any modern systems where the explicit signal change
> is needed?
>
> I see several options for this code in order to remove the use of signal:
> 1. delete the signal altogether, on the assumption that no modern system
> inherits an ignored SIGCHLD
> 2. switch to sigaction to force SIGCHLD to SIG_DFL
> 3. switch to the gnulib execute module, which makes this code portable to
> mingw (the current fork/exec sequence excludes mingw, which lacks fork),
> and in the process isolates the portability problem of ignored SIGCHLD to
> gnulib and makes it so that install.c need not mess with <signal.h> at all
>
> I'm kind of leaning towards option 3, but want some agreement before
> proceeding, as it is certainly more invasive to the current code, even
> though it adds more portability as a result.

Invasive for a good cause ;-)
#3 sounds like it's worth a try, at least.

> But in looking at the gnulib code for execute.c, I don't see any mention
> of this SIGCHLD anomaly, where wait/waitpid fail if SIGCHLD is ignored.
> On the other hand, gnulib's execute module uses waitid rather than
> waitpid; I guess that this choice of API is immune to the SysV behavior?

Coreutils has a test for the install bug that prompted adding
the signal call: tests/install/trap, so at worst, we should discover
quickly whether execute.c needs a similar work-around.