Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-11 18:12:49

On Fri, 11 Feb 2011 15:01:35 +0100, Jeff Flinn  
<TriumphSprint2000_at_[hidden]> wrote:

> [...]The myriad of stream behaviour, stream ends, and methods of  
> specification to me do not best represent the problem domain.
> [...]So having stdin, stdout, stderr Initializers with constructors or  
> factory functions:
>
> stdin_from()
> stdin_from(const path&)
> stdin_from(const file_descriptor_source&)
> stdin_from(const file_descriptor_ray&)
>
> stdout_to()
> stdout_to(const path&)
> stdout_to(const file_descriptor_sink&)
> stdout_to(const file_descriptor_ray&)
>
> stdout_to()
> stderr_to(const path&)
> stderr_to(const file_descriptor_sink&)
> stderr_to(const file_descriptor_ray&)
>
> is to me conceptually much simpler than dealing with stream behaviour,  
> stream end and context classes. It also minimizes copying and heap  
> allocated handles.

You basically replace boost::process::handle with various types? This  
makes redirecting to a file very simple indeed.

Some stream behaviors would be still required though - somehow you need to  
create a pipe for example? Stream behaviors would be called differently  
but they would still return two stream ends. These could now be objects of  
different types (so the return type is not necessarily called stream_ends  
either).

What I like about your idea is that it's not required anymore to use two  
objects (stream ends as they are currently called) if you really need only  
one (for example to redirect to a file). I also like that a stream  
behavior (or whatever it is called then) which creates for a example a  
pipe wouldn't need to return a parent and child end but can return a read  
and write end.

How would the library support inheriting file descriptors > 2 on POSIX?  
With something like fd(int, const file_descriptor_source&) and fd(int,  
const file_descriptor_sink&)?

> [...]Sorry, my thoughts didn't make it all the way out of my finger  
> tips. I meant boost::process::child has a std::map<stream_id, handle>   
> data member. Once the child process has been initialized/launched there  
> is no need to know about any handles. Only the process id/handle is  
> required when one needs to wait on the child process to complete. My  
> view is that any stream definition info needing to be accessed after  
> initialization does not belong in the child process class.

The stream definitions are in the context class. The map in the child  
class is for stream ends to communicate with the child process. If you  
create for example a pipe and want the child process to write to stdout,  
the read end of the pipe is stored in this map.

Boris