New? idea

[Guy Harris]

If it shouldn't be implemented, USG UNIX is in trouble - from SIGNAL(2),
UNIX 3.0 User's Manual:

	...SIGCLD	18 (not reset when caught)

	...SIG_IGN - ignore signal
		The signal is to be ignored.  Also, if 'sig' is SIGCLD,
		the calling process's (shouldn't that be process'? -gh)
		child processes will not create zombie processes when
		they terminate; see exit(2).

So

	signal(SIGCLD, SIG_IGN)

will disown all child processes that exit while SIGCLD is being ignored.
The signal SIGCLD is delivered whenever a child process exits; this is
sort of like the SIGCHLD in the Berkeley job control code, which is delivered
whenever the state of a child process child changes - this includes exits,
and also includes stopping, etc..

I remember reading some code, I think in the C shell, which does

	signal(SIGCHLD, SIG_IGN)

>From what I could see, the kernel does the same thing whether the action
for SIGCHLD is SIG_DFL or SIG_IGN; i.e., the default action for SIGCHLD
is to do nothing.  The same is the case with the USG SIGCLD (i.e., if you
don't catch it, it's as if you ignored it except that zombies are created).
Is there any difference between 4.xBSD's handling of SIGCHLD if the action
is SIG_IGN or SIG_DFL?  And, if not, and if all cases where SIGCHLD was
ignored the code were changed to reset it to SIG_DFL, could the SIGCLD
and SIGCHLD signals be combined?  (The S3 manual says that SIGCLD is
included only for compatibility with "other versions of UNIX", and is not
guaranteed to behave the same in future releases of UNIX; it's "use in new
programs is strongly discouraged."  However, that signal still appears in
System V, albeit with the same caveat, and the S5 "init" uses it.)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy