Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!chinet!mcdchg!usenet
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix
Subject: Re: Children's exit() status
Message-ID: <10104@mcdchg.UUCP>
Date: 2 Jun 88 18:53:23 GMT
Article-I.D.: mcdchg.10104
References: <4626@mcdchg.UUCP> <7963@mcdchg.UUCP>
Sender: usenet@mcdchg.UUCP
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 46
Approved: usenet@mcdchg.UUCP

In article <7963@mcdchg.UUCP> davek@heurikon.UUCP (David Klann) writes:
>... using wait(2) with SIGCLD is a possibly bad way to go
>becaus of the warnings in signal(2) ...

SIGCLD is specific to System V (well, there is an alias for it in
current 4BSD <signal.h> files, but ignore that).  On System V, with the
exception of the code in VR3 that was taken from Berkeley's `jobs'
library, it is true that there is no reliable way to catch most
signals.  SIGCLD, however, is special.  It is unlike every other signal
in SysV in everything except the delivery mechanism.

Because of the special way SIGCLD is implemented (read: a kludge :-) ),
if your signal catching function reads

	/* ARGSUSED */
	child(signo)
		int signo;
	{
		int status, w;

		w = wait(&status);
		... do stuff with w & status ...

		/* this should be the last line */
		(void) signal(SIGCLD, child);
	}

you will never miss a child signal, even though if two children exit
`simultaneously' they will only generate one signal.  The reason is
that the special kludge *regenerates* the signal on the way out of
child(), if there happens to be another exit to pick up.

If you put the signal() call before the wait(), you will get an
endless recursion since there will always be at least one exit status
ready.

>The way to ensure catching all of your children is to use the Release
>3 sigset(2) group of calls (I assume you're running Release 3). ...

This will work only when the kludge is present.  Even given reliable
signals, a signal catcher may still run only once for multiple
signals.  So as long as you are relying on the SIGCLD kludge, you
might as well use the simpler interface above.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris