SIGCHLD and signal handlers (again)

[James Bailie <jazzturk home com>]

Andrew Wood writes:

> Thanks - your post cleared up some things for me; means I should be able to
> get rid of zombies *properly* in *all* cases in my project.

In retrospect, I see my post wasn't completely accurate. I'm surprised no one
corrected me.

In particular, if the system your programming resets signal handlers to their
defaults when signals are triggered, then you need to assign the handler to
the signal again in the handler itself (or set the signal with sigaction() to
change this behaviour). This is one case where signals occuring during
the execution of the signal handler are lost, as the default action for
SIGCHLD is SIG_IGN. If you reassign the handler early on in the handler
itself, you will have to take precautions to make the handler reentrant.

Then there's the case where one or more children die very close together in
time, before the handler can be run. This is the situation I was referring to,
where the signals are not queued, and only one SIGCHLD is delivered to the
parent.

So there are two reasons I know of to loop on waitpid() in a SIGCHLD handler.

Importantly, the sigaction() system call can also control whether a system
call interrupted by a signal handler is restarted when the handler has
completed. Say you have a Gtk+ app which your users can interrupt with a
SIGINT when it's sleeping in a call to select() or a read() on a socket. You
can use sigaction() to PREVENT the call to select() from being restarted on
exit from the SIGINT handler, but make sure the call to select() IS restarted
after a SIGCHLD has been handled.

There. Think I got it right this time.

-- 
James Bailie

http://users.imag.net/~lon.jbailie