From: John Maddock (john_at_[hidden])
Date: 2004-06-23 05:15:54
> > Normally you don't want to leak resources, which may or may not involve
> > zombies. And even if zombies are involved, reclaiming them need not
> > require a signal handler, which was my original point.
> oh ? Any call to fork() should be accompagnied by a call to wait()
> (or one of its cousins such as 'waitpid()'). The only question is whether
> that has to happen synchronously or asynchronously.
> Calling 'wait()' synchronously basically means to block right after
> has been called untill the child process terminates. One technique that
> uses this approach is to detach the subprocess, i.e. to fork twice, and
> the grand-child carries out the actual task, the child finishes
> The much more frequent situation is to call it asynchronously, i.e. the
> would be either executed from inside the SIGCHLD handler or somehow
> by it (such as a semaphore, which is reentrant).
> Do I miss something ?
Surely there's no need to call wait until the parent asks for the return
value: In fact I'd kind of like the library to be similar to Boost.Threads -
a child process is an object that can be waited upon, the library would only
need to do something "fancy" like installing a signal hander, if the child
object's destructor is called, without the object ever being waited upon.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk