Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Matus Chochlik (chochlik_at_[hidden])
Date: 2012-08-23 04:58:48

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.

>
> - 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.

>
> - 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).

>
> It  is certainly required to allow the library user to perform platform
> dependent things.
> But it feels wrong to require the library user to perform platform
> dependent things.

>
>
> As a summary:
> Even though I really think you did a really terrific job in wrapping the
> fork() and the like for Windows and for POSIX, I would not vote for
> inclusion into boost since the library user is still required to take a
> lot of care to write platform independent code. It is too hard to get it
> right and too easy to get it wrong.
>
> It seems to me that the amount of work required to turn Boost.Process
> into a library that allows to write platform independent code easily is
> rather small compared to what has been invested to get it to the current
> state. It would certainly be worth it.

Same here.

Best regards,

Matus