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