Can a parent process determine its child's status ?

[Chris Torek]

In article <22 at ctbilbo.UUCP> ray at ctbilbo.UUCP (Ray Ward) writes:
>The reason for the list and the calls to kill() is that SIGCLD is
>a bit, not a queue.

Although SIGCLD is indeed a bit, and not a queue, despite documentation
to the contrary in the many different and sometimes incompatible
versions of System V [as opposed to the many different and sometimes
incompatible versions of `BSD', in particular things derived from 4BSD
that are not 4.2BSD, 4.3BSD, or 4.3BSD-tahoe, and which should not be
called `BSD']....  Oops, seem to have lost the thread of that sentence.
:-)  Although SIGCLD is not queued, these calls to kill() remain
unnecessary.  SIGCLD is a special case hack.  It operates very much
unlike all other signals.

The following code will work:

	signal_type	/* either `int' or `void' depending on your version */
	catchcld()	/* achoo! */
	{
		int status, w;

		w = wait(&status);
		<sort through list of processes; note that pid `w' died>
		signal(SIGCLD, catchcld);
	}

This code, however, will *not* work, as it will recurse infinitely
(until it runs out of stack space):

	signal_type catchcld() {
		int status, w;

		signal(SIGCLD, catchcld);
		w = wait(&status);
		<sort through list...>
	}

The trick is that whenever SIGCLD is set to go to a user function
(`catch-a-cold' above), if there are any child processes ready to
be wait()ed for, System V Releases 1, 2, and 3 (at least) send a
*new* SIGCLD signal.  Thus, in the first example, for every exited
child process, catchcld() gets called recursively just after the
call to signal().

Under BSD, SIGCHLD (the moral equivalent of SIGCLD) acts just like any
other signal, and you must loop in the signal handler to collect all
exited children.  This is why 4BSD has a `wait3' call (or `wait4' in
4.4BSD; wait3 is now a C library compatibility function).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris