Paul Eggert wrote:
> Eric Blake <e...@byu.net> writes:
>> 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'd be a bit leery of assuming this. It was such a pervasive problem
> back in the day. I'd be a bit surprised if the problem were eliminated
> from all modern systems in all compilation modes.
>
>> 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?
>
> Yes, I expect so.
>
> The simplest thing is to leave install.c alone. Porting to mingw is low
> priority, surely.
[reviving an old thread...]
I was considering yet again the sole use of signal in install.c,
#ifdef USE_SIGNAL
signal (SIGCHLD, SIG_DFL);
#endif
It is tempting to remove it, but I've just confirmed that we must
not, as long as the linux-2.6.9 kernel is still relevant.
[it's still in use in every RHEL 4.7 installation]
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.
Darwin 8.11.0 still requires the signal call too, but there I merely
confirmed that coreutils' install/trap test would fail without the
signal call.
Which makes me think gnulib's wait-process.c will have to be changed
to deal with this.
