From: yyyyyyyyyyyyyyy@xxxxxx:
> ISO/IEC 9945-1:1996 says in 3.3.1.3:
> If a process sets the action for the SIGCHLD signal to SIG_IGN,
> the behavior is unspecified.
>
> Thus, Bruce Korb invoked unspecified behaviour according to
> the old standard. But the new draft adds a clause (under XSI),
> so with XSI conformance one cannot make SIG_IGN behave as SIG_DFL.
Bruce Korb may well have invoked unspecified behavior, but
the issue is that the allowed behavior is complete nonsense.
What does it really mean to pass through signal handling to
child processes? For signal disposition, there are three
choices:
1. Supply a handling routine. I don't suppose anyone recommends
that child processes call a routine in the parent process, so
that does not pass through, right?
2. SIG_DFL. Passing this trough should be fine. You get the
default behavior, don't you?
3. SIG_IGN. There's the rub. If you want to ignore SIGCHLD signals
so that your dead children are reaped immediately, you set SIGCHLD
handling to this value. >>>BUT<<< you also have to know that when
you exec() your children, you get undefined behavior. So, you the
application writer have to know to change signal handling after
fork() but before exec(). *AND* you have to know which library
calls do fork/exec-s for you, except they won't fix things
between the fork and exec, so you are left with timing holes. Fun.
There are two possible behaviors for ignored children: the exec-ed
program is in the SIG_DFL state, or it is in the SIG_IGN state.
Which cannot be relied upon. There is absolutely no practical use
for passing through the SIG_IGN handling. None at all. The _only_
purpose for doing so is to conform to what was written. Mistakenly.
So, please, fix it. Allow the pass through in some fashion for
anyone that really thinks it important, but allow sanity for everyone
else.
|