lkml.org 
[lkml]   [1996]   [Jun]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: On SIGCHLD signal semantics
On Fri, 7 Jun 1996, Marc Aurele La France wrote:

> > Single Unix Spec's version of System Headers & Interfaces, sigaction()
> > description:

> > If a process sets the action for the SIGCHLD signal to SIG_IGN, the
> > behaviour is unspecified [UX[ except as specified below.

> > If the action for the SIGCHLD signal is set to SIG_IGN, child processes
> > of the calling processes will not be transformed into zombie processes
> > when they terminate. If the calling process subsequently waits for its
> > children, and the process has no unwaited for children that were
> > transformed into zombie processes, it will block until all of its
> > children terminate, and wait(), wait3(), waitid() and waitpid() will
> > fail and set errno to [ECHILD]. ]]

> > The part between the [UX[ and ]] is a 'Unix extension' to the base X/Open
> > spec.

> Implementing this in Linux would fix my problem because, when SIGCHLD is
> set to SIG_IGN, the only way wait can return a pid is if that child exited
> while its parent's SIGCHLD handler was still something other than SIG_IGN.
> This means an application must spawn children before it sets SIGCHLD to
> SIG_IGN to get the broken behaviour (which strikes me as an explicit
> request for the time dependency).

> This is not perfect however because applications that expect the BSD
> behaviour might still break if they inherit SIG_IGN as their SIGCHLD
> handler (although they would do so reliably rather than unreliably). Thus
> I would still like to spit out a warning for the first wait call an
> application makes with an inherited SIGCHLD handler.

I'd like to retract that last paragraph. It occurs to me that there is a
way to interpret the above spec to deal with processes that call wait with
an inherited SIGCHLD handler. This may sound like stretching it a bit,
but please bear with me. The above spec can be broken down as a '"a"
except "b"' kind of statement. In the English that I speak and write,
this implies that a situation in "b" is also in "a". But "a" is "if a
process sets the action for the SIGCHLD signal to SIG_IGN", which rules
out an inherited SIGCHLD handler. Thus "b" applies only when the process
that calls wait has also explicitly set its SIGCHLD handler to SIG_IGN.

It follows that the behaviour that occurs when inheriting a SIGCHLD
handler of SIG_IGN is left as unspecified by both POSIX and the above
spec. It might well be that we are free to decide what we please as to
what that behaviour should be (including crashing the machine if so
decided). This might sound fascetious, but it is according to the "letter
of the law".

I propose instead that BSD semantics be followed until the process says
otherwise (by setting its SIGCHLD handler). This would mean that the
kernel only cleans out a child process if it terminates while its parent
has its SIGCHLD handler explicitly set to SIG_IGN.

Any dissenting opinions?

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



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