On Sun, 12 Sep 2010 00:53:17 +0200, Jeremy Maitin-Shepard <jeremy@jeremyms.com> 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
[...]