[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: Thu, 16 Oct 2008 20:11:31 +0200

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.

reply via email to

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