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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-09-11 12:07:53

On Sat, 11 Sep 2010 00:45:08 +0200, Jeremy Maitin-Shepard  
<jeremy_at_[hidden]> wrote:

> On 09/10/2010 03:21 PM, Boris Schaeling wrote:
>
>  > [snip]
>
>> I'm a bit confused: If you use fileno like above on Windows (0=stdin,
>> 1=stdout and 2=stderr) then we could also use an enumeration? At least
>> your implementation of inherit makes me think so that it's not the file
>> descriptor itself you are interested in but only the information whether
>> the standard input, output or error stream is configured. Then there
>> would be no difference between your and mine solution?
>
> It seems that you should just use a different name for the stream  
> behavior depending on which direction of pipe it will create. It would

This is what we basically had before when you had to pass a parameter like  
input_stream or output_stream:

ctx.stdin_behavior = bp::behavior::pipe(input_stream);
ctx.stdout_behavior = bp::behavior::pipe(output_stream);

Whether you pass a parameter or create two pipe behaviors for input and  
output streams doesn't make a big difference in the end.

Passing the information whether an input or output stream is configured to  
the delegate automatically will help to avoid mistakes though as you can  
write:

ctx.stdin_behavior = bp::behavior::pipe();
ctx.stdout_behavior = bp::behavior::pipe();

> be possible for the user to configure pipes for standard streams in the  
> direction opposite from what is standard (and also perhaps opposite from  
> what the user intended), but such a problem would likely be fairly  
> obvious to figure out.  You could also provide a bidirectional pipe

While it's fairly obvious I agree with Ilya (I think he pointed it out)  
that passing the information to a stream behavior explicitly whether an  
input or output stream is configured is redundant as stream behaviors are  
attached to input or output stream delegates anyway.

> [...]Note: As I mentioned in another message, I think that the  
> parent-end of the pipe should be returned to the user as part of  
> configuring the stream behavior.  This would further reduce confusion  
> and chance of incorrectly configuring the direction.  The documentation  
> could also address this.

With pipe you mean the pair of handles created by pipe? Where and why do  
you want to return it to the user? You want the user to explicitly set the  
pair of handles in context?

Boris