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