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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Daniel Trebbien (dtrebbien_at_[hidden])
Date: 2010-08-17 13:59:43

>
> * There are no POSIX and Windows specific classes anymore (posix_context,
> posix_child, win32_context, win32_child etc. have been dropped). Instead of
> trying to support each and every feature platforms provide extension points
> have been defined. They enable library users to "link in" those platform
> specific features they are interested in.
>

Excellent! I was hoping that the basic functionality would be
platform-independent. Now it is (mostly).

Is there a way to further remove platform dependence in handling the "exit
code"?

>
> * For the first time there is full support for synchronous and asynchronous
> operations. While asynchronous operations are built on top of Boost.Asio
> synchronous operations can be utilized without that library. Developers
> don't need to include any Boost.Asio headers and don't need to learn about
> Boost.Asio if they don't need asynchronous operations.
>

Interesting. Just out of curiosity, how did you implement asynchronous pipes
on Windows? Reads and writes from/to anonymous pipes that are created with
CreatePipe are blocking.

>
> * Stream behaviors define if and how standard streams can be used by a
> child process. While the various stream behaviors were defined as an
> enumeration or a boost::variant in previous Boost.Process drafts they are
> now implemented as classes. This makes it possible for developers to create
> new stream behaviors.
>
> * The code to start child processes on POSIX platforms has been carefully
> adapted to support multi-threaded applications (it turned out that this code
> was wrong in all Boost.Process drafts so far). The documentation explains
> what you need to take care of if you want to create child processes in a
> multi-threaded application on POSIX platforms.
>
> * The documentation is new and has been shortened and simplified. There is
> a user guide which can be read in 10 minutes and introduces all the major
> features of the library. The documentation is now also based on Quickbook.
>

The documentation looks good, and I like that it is based on Quickbook.

>
> * The test cases have been restructured to simplify them. They can now be
> run without patching Boost.Test and without setting a path to a helper
> executable in the source files - it's now all automatic. They are all passed
> successfully with MSVC 9 (2008) and g++ 4.2.1.
>
> What is currently missing?
>
> * Pipelines are not (yet) supported. If you have been using
> boost::process::launch_pipeline() there is nothing in this Boost.Process
> draft you can use instead. Depending on feedback this feature will be added
> again (there was simply no time yet to do this).
>
> We hope that after four years, two Google Summer of Code programs and
> countless drafts this new version will finally become the official
> Boost.Process library so many have been waiting for.
>
> Boris and Felipe
>

Here are some of my wish list items:

* Templating of the char type to support wchar_t. The "wchar_t version"
would use the wide versions of Windows functions:  CreateProcessW, etc.

* The ability to allocate within another process' address space, as well as
read/write from/to another process' memory.

* Integration with Boost Filesystem

Also, two questions:

* In the example that uses
<goog_1014815798>async_wait<http://www.highscore.de/boost/gsoc2010/process/user_guide.html#boost_process.user_guide.waiting>,
what happens if the child process exits before async_wait is called, and
before the status object is created? Will the end_wait function still be
called?

* Do I need to call wait or async_wait to prevent the accumulation of zombie
processes?