Re: [boost] Child processes

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
'fork()'
> 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
while
> the grand-child carries out the actual task, the child finishes
immediately.
>
> The much more frequent situation is to call it asynchronously, i.e. the
call
> would be either executed from inside the SIGCHLD handler or somehow
triggered
> 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.

John.