On 19 April 2016 at 01:06, Klemens Morgenstern
5. Replace all the on_exit() machinery with future continuations i.e.
launching a process *always* returns a future. If someone wants to hook code onto when the process exits, a future continuation is the right tool. Similarly for fetching return codes, or detaching oneself from the child. Python's new subprocess.run() returns exactly the struct your future also needs to return.
Well again: that would require the usage of asio all the time, I don't think that's very sensible.
I agree. Not everybody uses Boost.ASIO, even if it will be in the standard it does not mean that everybody will use that specific implementation. Also, if such a library needs only the task scheduling features of ASIO, would suggest to use Executor-based interface instead.
[2]: I refer to the stdout/stderr deadlock problem which is the
biggest reason anyone reaches for a process management library instead of just using the syscalls directy. The internals of the child i/o needs to be 100% async to prevent deadlocking. You can absolutely present publicly a device which appears to quack and waddle like a synchronous pipe for compatibility purposes, indeed AFIO v2 presents asynchronous i/o devices as synchronous ones if you use the synchronous APIs even though underneath the i/o service's run() loop gets pumped during i/o blocks.
I really don't think this is the case: boost.process should first of all be a wrapper around the syscalls, so I can use it on different platforms without and #ifdefs.
Exaclty.
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.
Same here and I believe the majority of people looking for such library just want to spawn processes in cross-platform contexts. (at least from memory of previous boost.process versions reviews) (BTW you may need to have a way to tell if a platform cannot launch another process? Not sure if a static_if or some kind of no-op would be useful)