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

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

On 09/14/2010 10:58 AM, Stewart, Robert wrote:
> Jeremy Maitin-Shepard
>> On 09/14/2010 04:04 AM, Stewart, Robert wrote:
>>
>>> 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.
>
>> From Wikipedia: "Process groups are used to control the
> distribution of signals."
>
> The idea is that you can send a signal to all members of a
> process group, but using that to monitor a signal from any member
> of the group via waitpid() seems quit within scope, particularly
> since that is part of the waitpid() interface.
>
> I'm also not familiar with the behaviors and uses of process
> groups so I don't know if this would just shift the problem in
> some way, albeit to presumably less common application types.

In addition to the fact that you could still run into the same problem 
if you allow users to change process groups (you would have to loop 
through arbitrarily many process groups), I feel that imposing 
non-standard restrictions, even if seemingly minor, is not really 
appropriate for a Boost Process library.

I took a look at the process spawning facilities in GLib and Qt 
(documentation only).  There might be other libraries that would also be 
relevant.  See:

http://library.gnome.org/devel/glib/2.25/glib-Spawning-Processes.html
http://library.gnome.org/devel/glib/2.25/glib-The-Main-Event-Loop.html

Note: The Main Loop documentation describes the "child watch" 
facilities, which are particularly relevant to our discussion.

http://doc.qt.nokia.com/4.7-snapshot/qprocess.html

The GLib approach in particular seems to be most relevant.  (Qt, I 
believe, tends to assume it has full control over the entire process, 
whereas Glib seems to attempt to be more modular and interoperable with 
other software, at least with respect to process creation.)

It seems a key goal is for Boost Process to be interoperable with the 
process creation in GLib and Qt.  GLib may also provide some useful 
design inspiration.