Boost logo

Boost :

Subject: Re: [boost] [boost.process] 0.6 Redesign
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-04-19 07:34:10


>> Currently you only have the async_pipe representation, which wraps
>> around a either ordinary posix-pipe or a named pipe on windows.
>> Now I do not think, that I need to make everything async, because I can
>> think of enough scenarios where this is a complete overkill. For
>> example, I might just want to pipe from one process to another:
>
> I meant internal implementation needs to be async. It's unavoidable
> unless your design is to be fundamentally broken.
>

Well, it's as broken as the system. That's good enough for me.

>> If I understand what you say here correctly, that this is what I
>> originally planned. But I decided that against that, because it is much
>> easier the current way and you can store all needed information in a
>> simple child. And actually you can detach the child.
>
> In this you enforce a design choice and consequence onto your users.
> For example you'll force your users to use smart pointers and memory
> allocation to stop the default behaviour you imposed on them. The way
> I suggested does not have these problems.

What? Everything there is movable, you don't need any smart pointer. As
a matter of fact, I originally designed the return type of execute to be
a template depending on the parameter, so that you'd have an
stdin/out/err member depending on whether or not you pipe that
somewhere. But I decided against that because that (despite being
overcomplicated) WOULD have required smart pointers.

>> Well again: that would require the usage of asio all the time, I don't
>> think that's very sensible.
>
> As I mentioned, the biggest reason to choose a child process
> management library rather than throwing one together of your own is
> that someone has solved the stdout/stderr deadlock problem for me. If
> you don't solve that problem for me, it's faster and easier to bodge
> together my own process library because your library delivers nothing
> of value to me.

Well, you have the faculties for that in the current boost.process
design. And if that ain't enough it can be built atop. Feel free to
build boost.apio :).

>> Ok now I am confused: you want me to make everything asio, so that
>> you'll always need boost.asio, but you want to eliminate the dependency
>> on boost.fusion? Why? That's definitely not going to happen, since I do
>> a lot of meta-programming there, this would become too much work for a
>> library which clearly needs other boost libraries. The only way I see
>> that happening is, when I propose a similar library for the C++
>> Standard, and that won't happen very soon...
>
> There is zero need for metaprogramming in a child process library. If
> you think you need it, you have the wrong design.
>
> ASIO is not like Fusion. ASIO is entering the ISO C++ standard. That
> makes it one day not-a-dependency.

Have you even looked at the design? Because it absolutley requires
metaprogramming and it is the only elegant choice. On Windows you have a
function overblown with parameters, making it unreadable. On Posix you
have to call several functions to get a process up. And my design has a
variadic function, which allows you to pass only the arguments you need.

> I *personally* think you should use ASIO rather than duplicating
> work. But you don't have to, feel free to rip bits out of AFIO v2
> into your own solution if you like. Mine is certainly much easier to
> borrow from.

What? I do that!? The Async Pipe has two
boost::asio::windows::stream_handle/boost::asio::posix::stream
descriptor. They are just packed differently, because it's a pipe, not a
stream.

>
>> The async stuff is second, and is a set of features, extending it. At
>> least that's the reason I need a process library, which is the reason
>> I'm working on that.
>
> I don't think you understand the stdout/stderr deadlock problem. Look
> into Python's subprocess.communicate().

Yeah right, because I don't think we should to everything async I don't
understand the problem. It's not like I implemented that deadlock enough
times myself.
If you try to solve a possible deadlock by making everything async and
multithreaded, it's like using GC because to avoid leaks. I want a C++
and not a java or python library, and that means to expose as much to
the developer as possible and keep the overhead optional.

So would you just design the library like the python equivalent?

How would you view this library?
http://templated-thoughts.blogspot.de/2016/03/sub-processing-with-modern-c.html


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk