Re: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]

Subject: Re: [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2011-02-11 22:16:47

On 11 February 2011 23:30, Boris Schaeling <boris_at_[hidden]> wrote:

> On Fri, 11 Feb 2011 16:39:35 +0100, Jeff Flinn <
> TriumphSprint2000_at_[hidden]> wrote:
>
>  [...]I think with the right abstractions the seemingly contradictory goals
>> can be accommodated. That's what I'm attempting to find. As stated at a
>> previous boostcon: "... abstractions are discovered not invented..."
>>
>>
>> IMHO, previous version of process have not discovered the proper
>> abstractions. I'm sure that the entirely different paradigms between windows
>> and posix have contributed to the difficulties so far. It's difficult to be
>> a master of the subject matter in both domains.
>>
>> I think building upon existing boost filesystem and iostreams libraries
>> and their abstractions that do successfully address platform differences
>> will make the effort more successful. Additionally I think it's mandatory
>> for a design to directly acknowledge the multi-phase constraints of the
>> fork/exec paradigm. Also it's mandatory to break down the historical
>> monolithic approaches into more tenable pieces.
>>
>
> Thanks for your comments, Jeff, Ilya and Nat! How would you (and others)
> feel about a Boost.Process library which only aims to replace std::system()
> with a more powerful function? You could configure the child process a bit
> (its streams, environment variables and a few more things) and that's all.
> This would be a less ambitious goal but obviously more easily to reach. I
> was under the impression that we want more? Maybe we still want more but
> settle realistically for this goal?

I've not caught up on all of the discussion about the pending review yet,
but it seems to be hitting a few familiar issues this time around,
unfortunately.

I'd like Boost.Process to either mimic the Python subprocess module (as Nat
mentioned) or to provide a few low-level pieces:

1. std::system replacement allowing me to do the call in an async way and
capture the output. Ideally implemented in such a way that a "process
pipeline" library could be implemented on top of Boost.Process. Pipelining
input / output between different work items is a more general domain than
fits in Boost.Process, IMHO.
2. Way to get process id in a platform independent way.
3. Way to look up location of processes and get a Boost.Filesystem path.
4. Version of "std::system" that works with Boost.Filesystem
5. Version of std::system that allows passing a custom set of environment
variables
6. Expose a "native_handle_type" from the library, whatever that native
handle type is.

There seems to be a lot of justified disagreement about what the high-level
view of the library should be, yet all but point 1 are almost trivially
implemented in a cross-platform way and entirely orthogonal to the rest of
any Boost.Process library. I'd like to see just points 2-6 addressed,
reviewed and released before tackling the bigger picture.

The disagreements over scope are a showstopper for any progress and threaten
to lead Boost.Process astray for another another couple of years unless they
are worked around, ie. by reducing scope, perhaps to the point that
Boost.Process starts life as a basic utility library.

Evolutionary rewrites and breaking changes are much better than nothing.
After all, we're up to V2.x of Boost.Spirit and V3 of Boost.Filesystem and
all versions have been immensely useful for us end users.

Kind Regards,
Darren