> * There seems to be no good reason to special case SIGCHLD in signal_handler.  The comment about infinite recursion has no obvious interpretation to me.  Fortunately, this is irrelevant on platforms with sigaction, because the handler remains installed anyway!

I think that it's possible, on certain systems, that setting a signal handler for SIGCHLD while there is un unwaited child (zombie) process triggers a new sending of SIGCHLD.
See http://standards.ieee.org/reading/ieee/interp/1003-1-90_int/pasc-1003.1-132.html:
"The SIGCHLD or SIGCLD were used for implementing job control.
Since I had implemented job control for both BSD and System V,
I pointed out to the standards group that except for SIG_DFL,
these signals had different semantics.

If a signal handler was set for SIGCLD, then a signal would
be generated if there were any unreaped child processes.
When the signal handler was caught in System V, it was reset
by default to SIG_DFL.  However, if a process did not
reap a child and instead reestablished the signal handler,
it would go into an infinite loop since the signal would
be generated again.  The SIGCLD SIG_IGN behavior was that
the system reaped the child when it completed so
that the application didn't have to deal with it.
However, I believe that a process blocked in wait() would
be awakened, but I am not certain of this.

The SIGCHLD signal on the other hand was generated when
a child completed if a signal handler was set at that time.
No signal would be generated if a signal handler was
established while there was waiting children.
The SIGCHLD signal was also generated when a child process stopped.
I believe that BSD treated SIGCHLD SIG_IGN the same way
that it treated SIGCHLD SIG_DFL."

So, there might exist out there a couple systems that merrily mix SIGCLD and SIGCHLD, and re-raise a SIGCHLD when setting a new handler for it when unwaited children exist (which is the case in signal_handle, since child processes can't be waited for before the main thread gets to execute the handler it set up).