Boost logo

Boost :

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


On Sat, 11 Sep 2010 20:36:17 +0200, Jeremy Maitin-Shepard
<jeremy_at_[hidden]> wrote:

> [...]
>> 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.
>
> The main issue is that I would like the same facilities for configuring
> std{in,out,err} to also be usable for arbitrary file descriptor numbers
> on POSIX, and for those file descriptors, you cannot assume any
> particular direction.

Indeed. But as context doesn't support arbitrary file descriptors those
must be configured differently anyway. Please have a look at
<http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/example/file_descriptors_setup.cpp>.
There are two pipes used to create file descriptors 3 and 4 which should
be inherited by the child process. As the pipe stream behavior is used
explicitly the user knows if 3 and 4 should be read or write ends of the
pipe. The user can pass the information to the pipe stream behavior while
the context indeed can't (in this example there is still a boolean value
used).

>>> [...]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?
>
> I think I explained this more clearly in another e-mail in reply to you.

I'll try to find it although I slowly get lost in this huge thread. :)

Boris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk