Messages in this thread |  | | Date | Tue, 4 Jun 1996 15:13:38 -0600 (MDT) | From | Marc Aurele La France <> | Subject | Re: On SIGCHLD signal semantics |
| |
On Tue, 4 Jun 1996, Theodore Y. Ts'o wrote:
> 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 | | +----------------------------------+-----------------------------------+
|  |