Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.HP.COM (Bob Lenk)
Newsgroups: net.unix-wizards
Subject: Re: System V and SIGCLD
Message-ID: <630009@hpfcdc.HP.COM>
Date: Fri, 3-Oct-86 16:07:05 EDT
Article-I.D.: hpfcdc.630009
Posted: Fri Oct  3 16:07:05 1986
Date-Received: Tue, 7-Oct-86 19:56:57 EDT
References: <2389@hcrvx2.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 35

> >Also, the
> >precise semantics of how SIGCLD is "queued" do not agree between System
> >V documentation and implementation, so there could be disagreement on
> >what to standardize.
> 
> Could you explain this a little bit further ? In what way, does the
> implementation differ from the documentation ?

The System V Release 2 manual says, "... while the process is executing
the signal-catching function, any received SIGCLD signals will be queued
and the signal-catching function will be continually reentered until the
queue is empty."

A more accurate description would be something like:

If _signal_ is called to catch SIGCLD in a process which currently has
terminated (zombie) children, a SIGCLD signal is delivered to the
process immediately.  Thus if the signal-catching function re-installs
itself, the apparent effect is that any SIGCLD signals received due to
the death of children while the function is executing are queued and the
signal-catching function is continually reentered until the queue is
empty.  Note that the function must re-install itself after it has
called _wait_(2).  Otherwise the presence of the child which caused the
original signal will cause another signal immediately, resulting in
infinite recursion.

> I have a stake in SIGCLD because one fairly large program that I have
> written depends upon SIGCLD

If your program works, it probably uses SIGCLD as I've described, and
the behavior agrees with the documentation.  Problems occur when programs
don't use it in this way (eg. re-install the handler before calling
wait).
			Bob Lenk
			{ihnp4, hplabs}!hpfcla!rml