Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: System V / SIGCLD questions...
Message-ID: <17457@mimsy.UUCP>
Date: 11 May 89 22:52:13 GMT
References: <565@lehi3b15.csee.Lehigh.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 48

In article <565@lehi3b15.csee.Lehigh.EDU> murrey@lehi3b15.csee.Lehigh.EDU
(Erik Murrey) writes:
>If I have spawned a few children, and one just did an exit(), then my
>reapchildren() signal handler gets called.  It does a wait(), gets the
>exit status, and gets out of there (after resetting the SIGCLD
>signal).  If by chance a second child dies while we are within the
>reapchildren() handler, I never get notified of it...

Your analysis is right, but this is not in fact what happens.  In
System V (all releases for all hardware platforms, for once), SIGCLD
works differently from every other signal.  The default action for
SIGCLD is to do nothing; the `ignore' action for SIGCLD is to discard
exiting children; and the `catch' action is as usual.  But when the
signal is set from any previous disposition to `catch', if there are
any pending exited children, a new SIGCLD signal is generated.

Loosely:

/* signal system call */
	if (sig == SIGCLD)
		switch (action) {
		case SIG_DFL:	/* default action is to ignore */
			... nothing special ...
			break;
		case SIG_IGN:	/* ignore action is to flush */
			... flush any children ...
			break;
		default:	/* catch: regenerate */
			... set handler ...
			if (there are children)
				psig(u.u_procp, SIGCLD);
			break;
		}

This means that a catcher routine written as

	catch()
	{
		int w, status;

		signal(SIGCLD, catch);
		w = wait(&status);
	}

recurses infinitely as soon as one child exits.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris