On Wed, Apr 23, 2003 at 08:53:00PM +0100, Graeme Hewson wrote:
> The intention of the signal() call is to tell the kernel that we're not
> interested in knowing anything apart from the stuff we inspect in
> wait_for_child(), and that the kernel shouldn't make the child a zombie
> when it exits. When we call wait_for_child() we already know the child
> process has exited (or will shortly) due to EOF or some error on the
> pipe. There are no signals involved, since we don't set up a handler.
> Given the timings involved, I think the "signal(SIGCHLD, SIG_IGN)"
> call is no more than nicety.
It's not even a nicety - at least on Solaris 8, if it's there, and the
child process terminates with a signal, the parent doesn't find out that
it did so, as per:
If any of the above functions are used to set SIGCHLD's
disposition to SIG_IGN, the calling process's child
processes will not create zombie processes when they ter-
minate (see exit(2)). If the calling process subsequently
waits for its children, it blocks until all of its children
terminate; it then returns -1 with errno set to ECHILD (see
wait(2) and waitid(2)).
in the Solaris "signal(3C)" man page; it just finds out that there are
no children left, it doesn't find out why the child exited, so it can't,
for example, report that it crashed with a particular signal.
I've checked in a change to remove the "signal()" call in question.
