Re: fork()/exec() dumping

["Michael J. Hammel" <mjhammel graphics-muse org>]

Thus spoke Erik Mouw
> On Tue, 22 Jun 1999 14:51:12 -0600 (MDT), gtk-app-devel-list@redhat.com (Michael J. Hammel) wrote:
> > Thus spoke Erik Mouw
> >>        /* parent code: just wait for the child to exit */
> >>        /* you can also install a signal handler for SIGCHLD */
> >>        waitpid(pid, &status, WUNTRACED); /* anti zombie */
> > 
> > You don't want to wait on the child if you exec().  You should do a SIG_IGN
> > for children that call exec() or you'll end up with zombies.
> 
> True, but that only works with the System V SIGCLD signal. AFAIK, it is
> not supported by the POSIX SIGCHLD (note the "H") signal. Since most
> modern Unix variants claim to be POSIX complaint, you have to
> wait()/waitpid() for the child.

According to Stevens:

   POSIX.1 does not specify what happens when SIGCHLD is ignored, so this
   behaviour [ignoring the child] is allowed.

   4.3+BSD always generates zombies if SIGCHLD is ignored.  If we want to
   avoid zombies, we have to wati for our children.

   With SVR4, if either signal or sigset is called to set the disposition of
   SIGCHLD to be ignored, zombies ar never generated.

The issue of zombie creation is related to whether a signal handler has
been installed or not.  If no signal handler is installed (SIG_IGN is set)
then for both POSIX and SVR4 boxes you don't need to wait for the child to
exit.  If you're on a BSD 4.3 derived Unix box (that is not POSIX compliant), 
you'd probably want to do the waitpid() call.

The problem here is that the original question related to the use of
exec().  Since exec() doesn't exit the child routine - it replaces the
running process with another process - the child never returns.  It's
questionable whether waiting on the child is "a good thing" or not.
-- 
Michael J. Hammel           |
The Graphics Muse           |    Sarcasm is just one more service we offer.
mjhammel@graphics-muse.org  |
http://www.graphics-muse.org