Maybe a bit of history will help resolve the SIGCHLD problem.
System V Release 2 had a signal named SIGCLD and BSD 4.1 has
a signal named SIGCHLD which were both referred to as
sig child.
Both of these were added to earlier version of UNIX so both
were added in a way that would not affect existing
programs by default. Thus, their default behavior was
to behave is if the signal were ignored. Thus, no blocking
call would be generated by either of these signals.
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 SIGHCLD 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 SIGHCLD SIG_IGN the same way
that it treated SIGHCLD SIG_DFL.
The standard adopted the BSD SIGHCLD signal semantics with the
following changes:
1. The SA_NOCLDSTOP flag was added so that programs that
did not expect a signal on stop would not be affected.
2. The behavior of SIGCHLD was made unspecified when SIG_IGN
is specified.
The problem that is being presented is the case in which
a process has SIGCHLD set to SIG_IGN and then execs a new
process. A conforming application would not set SIGCHLD to SIG_IGN
since the standard leaves this behavior unspecified. An application
that does set SIGCHLD to SIG_IGN should set it back to SIG_DFL
before the call to exec.
The standard clearly states that signals set to SIG_IGN by
the calling process image shall be set to be ignored by
the new process image. However, the fact that the behavior is
unspecified, allows an implementation to treat this
is if SIG_DFL were set and not automatically reap children,
even if setting to SIG_IGN by the process itself would reap children.
David Korn
research!dgk
yyy@xxxxxxxxxxxxxxxx
|