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

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

On Sun, 12 Sep 2010 00:53:17 +0200, Jeremy Maitin-Shepard  
<jeremy_at_[hidden]> wrote:

> [...]
>> We need both ends in create_child() as the function returns a child
>> object. It is the one used by the parent process to possibly communicate
>> with the child process: One end is passed to the child process and the
>> other end remains in the parent process so it can communicate with the
>> child process.
>
> I was just suggesting the use of a custom struct rather than std::pair,  
> so that you would have named members rather than first and second, to  
> avoid confusion about the meaning of first and second.

OK, I'll change it.

> However, in some other e-mails, I suggest that boost process shouldn't  
> itself hold on to the parent end of pipes and store them in  
> child_process instances for the purpose of providing get_stdin(), etc.  
> Instead, the parent end of the pipe is returned to the caller in the  
> course of setting up the mapping, and then boost process doesn't need to  
> do anything with it after that.  I think this leads to a cleaner  
> interface, since with the current interface, get_stdin, etc. are always  
> present in child_process but only meaningful if you happened to have  
> configured a pipe on the corresponding file number.

I see. As the child object is returned by create_child() though it seems  
to be a reasonable place to store the parent's ends? Maybe get_stdin() et  
al shouldn't return a pistream or postream though but the handles? This  
would also help if you want to use asynchronous I/O only and don't need  
the stream objects anyway?

> [...]Then you could have:
>
> ls_ctx[bp::stdout] >> bp::pipe() >> less_ctx[bp::stdin];
>
> write_file_descriptor_t ls_3 = ls_ctx[bp::stdout] >> bp::pipe();
>
> The additional advantage of tagging the file descriptor types with  
> read/write is that it can provide additional type safety if you then use  
> them with either boost iostreams or boost asio.
>
> Note: My imagination might be running a bit too wild with these last  
> syntactic suggestions, but in any case I think it demonstrates that you  
> can support arbitrary file descriptor mappings on POSIX without  
> sacrificing the quality of the portable interface.

While an interesting idea I think this is better done in a Boost.Pipe  
library if we don't want Boost.Process to be delayed even further. :)

Boris

> [...]