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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-14 13:43:35

On 09/14/2010 04:04 AM, Stewart, Robert wrote:

 > [snip]

> Indeed, calling waitpid() for each child, in turn, is not a good
> idea from a scalability perspective.  Putting all of
> Boost.Process' children into a unique process group and using
> waitpid(), with WNOHANG, to wait for children in that process
> group could work though.

The process group approach does have some nice properties, but I'm not 
sure it is reasonable for the library to impose such a restriction. 
(Maybe it is, I am simply not sufficiently familiar with process groups 
and their intended purpose/practical use to know.)  One thing of note is 
that a process can change its own process group id.

> If the client can control the process group of any child created
> with Boost.Process, then the library can track the process groups
> that have been specified and call waitpid() for each in turn.  If
> the PID of the terminated child is not recognized, then, it must
> have been created by other code in the process using one of the
> process groups given to the library.  In that case, a callback
> function would permit the library to inform the client that such
> a child terminated.  That doesn't help when the client cannot
> communicate such information to a third-party library that wants
> SIGCHLD.  Sadly, even chaining SIGCHLD handlers won't help in
> that case.

To some extent, any library that doesn't provide such an interface is 
inherently broken in terms of interoperability.  The C system() function 
would still work as advertised, since it blocks SIGCHLD, but due to that 
blocking, should probably be avoided in many cases.

> Here's another idea: if Boost.Process managed one child process
> that itself actually created the children, and communicated their
> creation and demise via pipe or socket, then that process can use
> a SIGCHLD handler with impunity and Boost.Process, in the
> grandparent process, will only be informed of the demise of
> grandchildren created by the library.
>
> Since creating a child process to manage grandchild processes is
> heavier weight than the process group approach, but the latter
> won't always work, perhaps the library could offer both options.