Re: [boost] [boost.process] 0.6 Redesign

Subject: Re: [boost] [boost.process] 0.6 Redesign
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2016-04-18 20:07:40

On 19 April 2016 at 01:06, Klemens Morgenstern <klemens.morgenstern_at_[hidden]>
wrote:

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