$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [process] Formal review results
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-09 15:00:22
Am 09.11.2016 um 19:45 schrieb Antony Polukhin:
> The Boost.Process library is accepted.
Awesome.
> Congratulations to Klemens, and thanks to everybody who reviewed the library!
>
> The votes were as follows:
> +   Johannes
> -   Niall Douglas
> +/- Tom Kent
> +/- Nat Goodspeed
> +   Paul A. Bristow
> +/- Bjorn Reese
> +   Edward Diener
> +   Boris Schäling
> +/- Raphaël Londeix
> +   Klaim - Joël Lamotte
>
>
> Legend:
> + accept
> - decline
> +/- accept conditionally
>
>
> Separate thanks to Gavin Lambert for providing a solution to
> deadlocking problem.
>
> Additional thanks to Nat Goodspeed, Niall Douglas, Gavin Lambert,
> Raphaël Londeix and Bjorn Reese for spending significant amount of
> time on discussing, reviewing or testing the library.
And not to forget, thank you for managing the process!
>
>
> -- Quick review summary --
>
> During the review multiple technical issues were raised and as far as
> I know, Klemens already working on them. The biggest win of the review
> - is a fix for possible deadlock with pipes.
I'm glad to report that this is already fixed.
That did however allow one additional feature: with the pipe 
automatically closing, you can now use a part of the asio stuff with 
bp::spawn.
asio::io_service ios;
std::future<std::string> fut;
bp::spawn("foo", std_out > fut, ios);
Not sure this is the smartest thing to do, but it could make sense for 
some simple applications.
> The most controversial part of the library is it's interface. Many
> comments were addressing:
> * passing arguments
> * starting process right in `system(...)` function
>
> Current approaches have benefits and drawbacks, other approaches have
> different benefits and drawbacks. At this point some people agree that
> the current approach is the lesser evil.
I'm very glad to hear that.
> Reviewers also wished to have better/richer documentation.
I'll keep working on that. Additionally, Nat will help me create a 
useful extension-interface, so that will become public and be 
documented. With that in, there will also be more information on how the 
library works internally.
>
> P.S.: Please continue with the discussion and report issues that would
> help to improve the library.
>