System V and SIGCLD

[Chris Torek]

In article <709 at cheviot.uucp> lindsay at cheviot.newcastle.ac.uk
(Lindsay F. Marshall) writes:
>The following code goes into an infinite loop on System V :-
>
>	trap(sig)
>	int sig;
>	{
>		printf("trapped SIGCLD\n");
>		signal(SIGCLD, trap);	/* reset handler */
>	}
>
>	main()
>	{
>		signal(SIGCLD, trap);
	[...]

>[...] if you do not reset the handler the system seems to set it to
>SIG_DFL, meaning that you will loose [sic] any SIGCLD signals between
>the handler's exit and your getting a chance to call signal again.

Your loop behaves in accordance with my formulation of the System
V internals for SIGCLD.  I posted them some time ago, and received
no comments, which I (tenatively) take to mean that I was completely
correct.  Given that particular implementation, *any* SIGCLD trap
routine which does not do at least one `wait' system call before
doing another `signal(SIGCLD, trap)' will recurse until it runs
out of stack space.

Here is what System V really does (by my analysis):

1.  Any time a child exits, the kernel examines its parent's SIGCLD
    disposition, and takes one of the following actions:

	SIG_DFL
		The child is left as a zombie (`<exiting>').  No
		other action taken.
	SIG_IGN
		The child is silently discarded; no <exiting>
		process left behind, and the parent cannot collect
		the child's exit status.
	other
		The kernel sets the bit for SIGCLD in the parent's
		pending signals mask.  When the parent is scheduled,
		the kernel arranges to run the trap routine (and
		the kernel will then change the parent's SIGCLD
		disposition to SIG_DFL).

2.  In the kernel signal system call code, if the user is altering the
    action for SIGCLD, again the kernel examines the new disposition:

	SIG_DFL
		No action taken.
	SIG_IGN
		All currently exited children consumed.
	other
		If there are any exited children, the kernel sets
		the bit for SIGCLD in the parent's pending signals
		mask.

This does not match the manuals; but it does seem to fit the actual
behaviour, and has a clear and `efficient' (but not necessarily
`clean') implementation.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu