Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-11 17:21:03
On 09/11/2010 01:47 PM, Boris Schaeling wrote:
> Maybe I misunderstand what you mean with process. But you need (and
> should use) only one worker thread no matter for how many child
> processes you wait. Your code can look like this:
> boost::asio::io_service ioservice;
> boost::process::status s(ioservice);
> s.async_wait(child1.get_id(), handler);
> s.async_wait(child2.get_id(), handler);
> s.async_wait(child3.get_id(), handler);
> There is only one worker thread within the ioservice object.
I assumed you were using waitpid with the specific pid of the child, but
I just took a look at the code and see that you are using wait (which
waits for any child, equivalent to waitpid with a pid of -1). This
indeed avoids the need for one thread per child process, but has the
serious drawback that it will silently eat all notifications related to
child processes not created by boost process, and therefore prevents any
other code in the same program from properly dealing with child processes.
Note that from a SIGCHLD handler, you could invoke waitpid with WNOHANG
once for each child process, and this way avoid the need to coordinate
regarding child process notification, but you would still need to
coordinate regarding SIGCHLD, and I think it would be very inefficient
to have to make one syscall per child process each time SIGCHLD arrives.
If you arranged to have all of the child processes created by boost
process actually be grandchildren of the main process, and children of a
special forked process created by boost.process, then you could
simultaneously avoid coordination regarding SIGCHLD and waitpid, at the
cost of just one additional process. However, due to the need for an
additional process, I don't really like this solution either.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk