Re: [boost] [gsoc] Boost.Process done

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.