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

Subject: Re: [boost] [Boost-users] Brainstorming [WAS: Subject: Formal Review of Proposed Boost.Process library starts tomorrow]
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-12 02:33:58

Am 12.02.2011 04:16, schrieb Darren Garvey:
> 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.

I agree - boost.process should provide only the sync. wait (async. wait 
should be left).
Maybe boost.process or another library can provide the async. wait 
facility and the community has more time to discuss it.