Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk