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.