Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site humming.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!genrad!panda!talcott!harvard!humming!arturo
From: arturo@humming.UUCP (Arturo Perez)
Newsgroups: net.unix
Subject: Re: UNIX question
Message-ID: <106@humming.UUCP>
Date: Tue, 24-Dec-85 16:46:27 EST
Article-I.D.: humming.106
Posted: Tue Dec 24 16:46:27 1985
Date-Received: Thu, 26-Dec-85 03:50:46 EST
References: <156@uw-june.UUCP> <12600002@hpfcls.UUCP>
Reply-To: harvard!humming!woody!arturo
Distribution: net.unix
Organization: Kurzweil A.I. Waltham, Mass.
Lines: 35
Keywords: signals

In article <12600002@hpfcls.UUCP> rml@hpfcla.UUCP writes:
>> 
>> The problem is that several children may exit in quick succession.
>> Only one SIGCLD signal will be delivered, since the parent process
>> will (just this once) not manage to run before all have exited.
>> The sigcld handler has no way of determining how many children are
>> to be processed.
>
>It turns out that SIGCLD can be used reliably in System III and V.
>What is missing from the example is a call within the signal handler
>to re-install itself. 
>
>>	int
>>	sigcld()
>>	{
>>		int pid, status;
>>		pid = wait(&status);
>>		...
>>>>		signal(SIGCLD, sigcld);		/* add this line */
>>	}
>
>The signal(2) system call checks to see if any zombie child(ren) are
>present and sends the calling process another SIGCLD if there are.
>The signal handler is thus invoked recursively, once per zombie.
>Note that the reinstallation of the handler must follow the call to
>wait, or infinite recursion results.
>			Bob Lenk
>			{hplabs, ihnp4}!hpfcla!rml


This isn't correct. The problem is that the implicit 'signal(SIGCLD,
SIG_DFL)' is done AFTER the signal trapping function returns. Thus,
if you call signal from within the trapping function it doesn't do
you any good. At least, this is the way it works on our SYSV/BSD
hybrids.