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

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

Here is another update of the library (again ZIP file updated at  
<http://www.highscore.de/boost/gsoc2010/process.zip>; again changes in  
Subversion at <http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/>).

What has been changed?

* The library supports now configuring any streams (not only standard  
streams but whatever is supported on a platform). This is done through the  
new boost::process::context::streams array which replaces the  
stdin_behavior, stdout_behavior and stderr_behavior member variables. At  
the same time boost::process::child has been changed: This class doesn't  
provide the methods get_stdin(), get_stdout() and get_stderr() anymore but  
a single method called get_handle(). This new method expects a stream  
identifier as parameter and returns a boost::process::handle. It does not  
return a boost::process::istream or boost::process::ostream anymore as  
Boost.Process doesn't necessarily know if a stream is an input or output  
stream. This has the additional advantage though that those who like to  
use asynchronous I/O don't get a stream anymore (as they don't need one).  
Now you get a handle and decide yourself whether you want to initialize a  
stream (for synchronous I/O) or a pipe (for asynchronous I/O).

* Stream behaviors don't expect a boolean anymore to differentiate between  
input and output streams. A new enumeration called  
boost::process::stream_type has been defined to improve readability.  
Furthermore stream behaviors like pipe or named_pipe provide a new  
constructor to explicitly specify whether a child's input or output stream  
should be configured. This is required on platforms which support  
configuring arbitrary many streams (which means POSIX :).

* A bug was fixed in boost::process::detail::basic_status_service which  
caused problems when waiting asynchronously for child processes to  
terminate on POSIX platforms.

Again I'd appreciate if you could comment on the changes. Especially have  
a look at:

* boost::process::stream_type (in boost/process/stream_type.hpp) and  
boost::process::stream_id (in boost/process/stream_id.hpp). These types  
and files are new.

* the new constructors in boost::process::behavior::pipe,  
boost::process::behavior::named_pipe and boost::process::behavior::null  
which expect a parameter of type boost::process::stream_type. They allow  
developers to explicitly specify whether an input or output stream is  
configured as the setting overrides the parameter passed to operator()  
(have a look eg. at the test case called "test_posix" in  
<http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/test/child.cpp>  
to see why this is required).

* the class boost::process::context. There is no stdin_behavior,  
stdout_behavior and stderr_behavior anymore but a new array called streams.

* the class boost::process::child. As boost::process::context was changed  
to support basically arbitrary many streams boost::process::child had to  
be updated to provide access to them.

* the implementation of boost::process::create_child() (especially the  
POSIX code). As boost::process::context looks differently now  
boost::process::create_child() had to be updated.

* the test cases in  
<http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/test/child.cpp>  
to see how boost::process::context and boost::process::child are used now.  
The POSIX test cases in this file also use the new streams array to  
configure streams with file descriptors greater than 2 (search for  
"test_posix"; this is now definitely easier than before as no user-defined  
context class is required anymore).

What still has to be done?

* boost::process::context class should provide a boost::function member  
variable to bind a callback function instead of requiring developers to  
define a subclass and override setup().

* The standard constructor of boost::process::context still tries to  
inherit standard streams (which is a problem for Windows GUI applications  
which don't have standard streams).

* It might make sense to pass a string to boost::process::create_child()  
to specify command line options (instead of storing them one by one in a  
vector).

* It might be possible to somehow pass options to CreateProcess() on  
Windows (which is used by boost::process::create_child()).

* Examples and documentation must be updated.

Boris