Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.questions
Subject: Re: Question on fork(), exec(), kill()
Message-ID: <1991May30.102025.28166@thunder.mcrcim.mcgill.edu>
Date: 30 May 91 10:20:25 GMT
References: <1991May15.201821.15350@colorado.edu> <1991May15.215826.26327@athena.mit.edu>
Organization: McGill Research Centre for Intelligent Machines
Lines: 30

In article <1991May15.215826.26327@athena.mit.edu>, jik@athena.mit.edu (Jonathan I. Kamens) writes:

> You need to wait on your children to get them to go away; until you
> do that, they're zombies.

>   Here's my occasionally posted article about that:

> Unfortunately, it's impossible to generalize how the death of child
> processes should behave, because the exact mechanism varies over the
> various flavors of Unix.  [...]

If you just want to fork children, don't want them to bother you when
they die, don't care about preserving precise parenthood relationships,
and don't care about the return status from the wait or resource usage
or anything of the sort, you *can* do *that* portably.  All you need to
do is fork and have the parent wait for the child explicitly, then have
the child fork again, with the second-level child doing the real work
and the first-level child dying immediately after the second fork.

This way, the parent has no children left, because its only child
exited.  When the intermediate process died, init (PID 1) inherited the
second child and will worry about doing the wait() when it dies.

Not that this is always appropriate, but sometimes it is.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu