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: Eric Blake
Subject: Re: [PATCH] Replacement for the sigs_to_ignore hack in timeout.c
Date: Thu, 16 Oct 2008 07:07:32 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080914 Thunderbird/2.0.0.17 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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?

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj3PJQACgkQ84KuGfSFAYDb5ACfT34DqsCuMcdXfPnkuZ3N0wkf
EgkAmwYW8OMR53sJAdTggjOPvZ1BEfhY
=u7oV
-----END PGP SIGNATURE-----




reply via email to

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