> This change does not affect any kernel functionality. What it does
> do however is introduce warnings under certain circumstances with
> respect to SIGCHLD signal semantics. The circumstances addressed are
> when a parent process decides to wait for termination of one of its
> child processes, but does so with its SIGCHLD signal handler set to
> SIG_IGN. If the child process terminates while its parent is
> waiting, this is not a problem. But if the child terminates before
> the parent waits, then the parent will be told it has no children
> (because the kernel has already gotten rid of any indication of the
> child's existence). This can confuse the parent process.
> So far, I have been unsuccessful at digging up what various standards
> such as POSIX have to say about this case. So, I am hoping that
> someone on this list will point me to an already existing solution to
> this problem (and thus tell me whether I am out to lunch on this one
> :-)).
> >From POSIX.1, 3.3.1.3(2)(d):
> If a process sets the action for the SIGCHLD signal to SIG_IGN,
> the behavior is unspecified.
> And from the rataionale section of POSIX.1, B.3.3.1.3
> Historical implementations discard pending signals when the
> action is set to SIG_IGN. However, they do not always do the
> same when the action is set to SIG_DFL and the default action is
> to ignore the signal. POSIX.1 requires this for the sake of
> consistency and also for completeness, since the only signal
> this applies to SIGCHLD, and POSIX.1 disallows setting its
> action to SIG_IGN.
> The specification of SIG_IGN on SIGCHLD as implementation
> defined permits, but does not require, the System V effect of
> causing terminating children to be ignored by wait(). Yet it
> permits SIGCHLD to be effectively ignored in an
> impleemntation-independent manner by use of SIG_DFL.
> Some implementations (System V, for example) assign different
> semantics for SIGCLD depending on whether the action is set to
> SIG_IGN or SIG_DFL. Since POSIX.1 requires that the default
> action for SIGCHLD be to ignore the signal, applications should
> always set the action to SIG_DFL in order to avoid SIGCHLD.
^^^^^^
Bingo! Give that man in the corner with the red hat a SEEEgar :-)
So, because applications are, in general, not ensuring their SIGCHLD
signal handler is not SIG_IGN, the question boils down to: Should the
kernel do it for them (by always setting SIGCHLD to SIG_DFL on an exec
call)? In more general terms, is POSIX compliance the kernel's
responsibility? or is it the application's?
> So the bottom line is what we're doing is allowed by POSIX, and
> compatible with System V. Given that it's compatible with System V, it
> may very well be required by SVID and/or Spec 1170. If someone who has
> access to either SVID or Spec 1170, do please comment on this issue....
Yes, I wouldn't mind hearing from other, non-POSIX, fronts also.
Thanks.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: tsi@ualberta.ca |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+