Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-08-24 10:22:48

On 8/23/2012 4:58 AM, Matus Chochlik wrote:
> Hi,
>
> first of all I would like to thank you, Boris for your effort
> in writing this library. Recently I wrote quite a lot of code
> where (Boost.)Process would be of great help, provided
> some things were fixed.
>
> As most of the things I would like to be changed were already
> addressed by the previous posters to this thread, I'm going to use
> Roland's post (with which I agree 100%) and just add some notes.
>
> On Thu, Aug 23, 2012 at 10:18 AM, Roland Bock <rbock_at_[hidden]> wrote:
>> On 2012-08-18 17:31, Boris Schaeling wrote:
>>> Please have a look at the documentation and think about whether this
>>> library could fit into Boost. If you have more time, please download
>>> and play around with the new version. Concentrate on the bigger
>>> picture: Does the design make sense? Is it easy to understand? Can you
>>> do what you want to do? Does it look and feel like modern C++?
>> In reviewing previous mails in this thread I realized that I my comments
>> focused on the examples. I'll give my opinions on your questions here:
>>
>> - Does the design make sense?
>> Partially: I like a lot of aspects, for instance the initializers,
>> especially bind_stdin and Co. But to be confronted with Windows/POSIX
>> specific stuff for even the simplest tasks, is bad design in my eyes.
>
> +1
> + as others said, the special devices/'files' like /dev/null, NUL and friends
> should be platform independent if possible.

My thought is these may belong to the boost.iostreams library. Or this 
could be internalized by the platform executor for "unconnected" io 
channels.

>> - Is it easy to understand?
>> Yes and no. I mean, hell, yes! Much easier than handling fork and
>> opening pipes on my own. I did that myself and it would be so much nicer
>> using the current version of Boost.Process. But then my current code is
>> POSIX only. If I wanted to write platform independent code, I would
>> still feel lost.
> +1
> Not to say how lost might feel the people who didn't write the code
> but have to maintain/bugfix it.

In our organization, no platform dependent #ifdefs in client code is a 
precondition to a process library's use. Certainly extension points 
using platform specific code is required, but these are implemented as 
separate files that are appropriately included by each platforms project 
build system. Windows and POSIX use vastly disparate paradigms for 
creating processes that there is little to no reuse of code between the 
implementations. The only commonality are the type constructors, which 
provide the platform independence.

My version at https://github.com/JeffFlinn/boost-process demonstrates 
how this can be done.

>> - Can you do what you want to do?
>> Yes and no. Yes, I could replace my own current stuff. No, I want to
>> turn my current code into a platform independent version and I don't
>> know how unless I add a bunch of #ifdefs (and I don't want to).
> +1
>
>>
>> - Does it look and feel like modern C++?
>> Not to me. I'd expect a modern C++ process library to allow me to write
>> platform independent code where possible. Running a process, knowing the
>> environment, doing IO, waiting for it to finish, knowing the exit code
>> should not require different code and should behave in the same way
>> (e.g. the default environment for child processes should be the same).
>> Of course, if I want to know the child::pid or the child::proc_info and
>> do something with it: sure, that would be platform dependent.
> +1
>
> There certainly are differences between POSIX and WINAPI,
> but for the 95% of cases where you don't have to do special
> tweaking (handling SIGCHLD differently, etc.) the programmer
> should not be forced to do the #if-#else dance. This should
> be kept only for those who want/need to do that, but certainly
> not the default (simple) usage.
>
> Of course the POSIX-specific and WINAPI-specific things from
> which applications targeted only for a single platform could benefit
> should stay included (and maybe a couple more added).
>
> And, it is nice that there is a lightweight 'handle' to the child
> process, but I (and IMHO others) would not mind if there
> was a more heavyweight but also a more powerful equivalent
> (for example using RAII as others suggested to clean things
> up properly in a platform independent way).

I've struggled with just what a "child" entails as well. In our uses, a 
"child" instance may be a data member of a class. In trying to maintain 
process as a header only library, having the child hold a window's 
handle exposes windows.h too widely. I've thought the child could merely 
hold a pid (like posix), and the corresponding handle could be retrieved 
only when needed. I'm not sure yet if there are any issues with doing 
this in general on windows. This windows.h visibility is the motivation 
for the separate "monitor" type in my design. The monitor, typically 
being isolated to a few translation units as required, avoiding 
windows.h in any headers. There are both "monitor" and a 
"scoped_monitor" types.

Jeff