* 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?