Eric Blake <[EMAIL PROTECTED]> 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.
