Re: [boost] Child processes

From: Gregory Colvin (gregory.colvin_at_[hidden])
Date: 2004-06-23 01:04:01

On Jun 22, 2004, at 5:33 PM, Stefan Seefeld wrote:
> Gregory Colvin wrote:
>
>>> 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().
>
> yes, I'm only talking about posix systems.

But Boost usually cares about other systems as well.

>>>  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.
>
> I believe this should be left to the user. However, it would be
> nice if the library had some way of encapsulating various strategies
> to execute non-reentrant callbacks in a safe (and of course portable) 
> way.
> ...

It would be nice, but ...

>> You can also avoid blocking with a separate thread to do the wait(),
>
> that doesn't sound good: each sub-process would have to be accompagnied
> by a thread...that's quite a lot of unnecessary overhead, especially 
> since
> any reentrant solution would be able to dispatch all sigchilds from a
> single handler, i.e. the cost would be constant and not dependent on 
> the
> number of child processes.

Agreed.  I'm just trying to be sure all the possiblities are on the 
table.

>> or by calling waitpid() with WNOHANG in a polling loop.
>
> that's even more expensive.

Unless the app has a main event loop anyway?  Anyway, just another 
possibility.

> I think, any efficient solution to this problem will be quite 
> intrusive, i.e.
> it won't be possible to provide some sort of black box which you hand 
> over
> a callback. It needs tight integration with the rest of the 
> application such
> as an event loop or a general purpose signal handler (I used to run one
> thread per application to be responsible for all signals the process 
> could
> possibly catch (well, beside those that are thread-bound)).
>
> Probably the closest what you can get in terms of flexibility / 
> portability
> is ACE, as was already pointed out earlier. But that's a huge 
> framework, both,
> in terms of scope as well as code. That's the kind of scope though at 
> which such a
> facility is best implemented.

Yes, ACE looks like a lot of framework.  The Java design is much 
simpler.
I don't know that either is appropriate for Boost.