Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-17 17:07:04

On 09/15/2010 03:09 PM, Boris Schaeling wrote:
> On Tue, 14 Sep 2010 23:15:25 +0200, Jeremy Maitin-Shepard
> <jeremy_at_[hidden]> wrote:
>
>> [...]Syntax for these basic operations might be:
>>
>> context ctx;
>>
>> ctx[bp::stdout] = some_fd;
>> // Note: some_fd might be an open (filesystem) file, an open socket, etc.
>
> This is a syntax I basically like. I'm not sure though whether it should
> be ctx.stream_behaviors[] instead of ctx[]? As for Windows users this
> interface shouldn't be more confusing than the current one I prefer it
> to the hardcoded member variables stdin_behavior, stdout_behavior and
> stderr_behavior.

Potentially .streams  to be shorter, and also due to my note below.

>> [...]Although this syntax may seem a bit fancy, it would actually all
>> involve very little code, I think.
>
> I think for now I'll update the context class to support the syntax
> above but with existing stream behaviors. This should be a rather simple
> change hopefully everyone agrees with. Your ideas as interesting as they
> are open the box of Pandora and will start another huge discussion which
> I would prefer to engage in after we have managed to finish version 1.0
> of Boost.Process (which is hopefully this year ;).

There is likely to be one complication, which is that the 
.std{in,out,err} members of child_process would not be compatible with 
the new syntax, both because they don't account for additional file 
descriptors (could be fixed by using a [fd] interface as well) but also 
because in the existing interface the stdin member has a different type 
from the std{out,err} members, which is more problematic.

There are certainly various solutions, but I think the cleanest one is 
to remove those members and instead have the user obtain the parent end 
of the pipe in the process of configuring the stream.  (I imagine in 
addition to being the cleanest interface in terms of allowing the most 
to be enforced at compile time, it would also be the simplest to implement.)

I imagine you weren't intending to have to change that part of the 
interface in order to make the change for setting the stream behaviors, 
but I think it is relatively simple and an improvement in any case.