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

On Fri, 11 Feb 2011 15:01:35 +0100, Jeff Flinn 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 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