Re: [boost] Child processes

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2004-06-22 22:11:43

On Jun 22, 2004, at 4:31 PM, Stefan Seefeld wrote:

> Gregory Colvin wrote:
>
>> 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()

On systems that have fork().

> should be accompagnied by a call to wait()
> (or one of its cousins such as 'waitpid()').

On systems that have wait().

>  The only question is whether
> that has to happen synchronously or asynchronously.

And that question could be answered by the process library, or left
to the user.

> 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.

Which won't work if the parent cares about the child's exit() value?

> 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).

Which was the implementation Angus first suggested, which a few of
us pointed out was unsafe as written.  I meant to suggest the choice
could be left to the user.

You can also avoid blocking with a separate thread to do the wait(),
or by calling waitpid() with WNOHANG in a polling loop.

> Do I miss something ?

No, I think we agree on what the possibilities are for Posix.