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.