[lkml]   [1996]   [Jun]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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,

> 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.

> 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.



| Marc Aurele La France | work: 1-403-492-9310 |
| Computing and Network Services | fax: 1-403-492-1729 |
| 352 General Services Building | email: |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |

 \ /
  Last update: 2005-03-22 13:37    [W:0.100 / U:11.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site