Boost logo

Boost :

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

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

> 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
I don't know that either is appropriate for Boost.

Boost list run by bdawes at, gregod at, cpdaniel at, john at