[Boost-users] Review Results for Proposed Boost.Process library

Subject: [Boost-users] Review Results for Proposed Boost.Process library
From: Marshall Clow (mclow.lists_at_[hidden])
Date: 2011-03-07 18:40:36

----------------------------
Executive Summary
----------------------------

Boris Schäling's Process library was reviewed from February 7th, 2011 through February 20, 2011.  The library sparked a lively debate on the mailing list, and in the end, eight reviews were submitted:

          -  1 review ACCEPT
          -  2 reviews  CONDITIONALLY ACCEPT
          -  5 review  DO NOT ACCEPT
        
Since there was not a clear view in either the discussion or the votes that this library should be accepted:

             The Process library IS NOT ACCEPTED into Boost.

        There was considerable disagreement both about the scope of the library (what features to provide) and how the features were implemented. More than one alternate design was proposed, and the advantages and
disadvantages of various approaches (where to install signal handlers, having a single thread vs. one thread/child) were debated vigorously.

        However, there was a fairly broad consensus that the library, in its present state, was not ready to be included into Boost.

Thank you to everyone who participated, and especially to Boris and those who wrote a review.

I would like to encourage Boris to continue development of his library and to resubmit it for review at a future date.

----------------------------
Concerns voiced by reviewers (a partial list)
----------------------------

* There was considerable push back by the reviewers about the cross-platform interface; specifically the use of #ifdefs

* Artyom pointed out the possibility of deadlock given the current implementation, and a lack of wide-character support on Windows.

* Oliver said "I'm missing the possibility to send signals to a process and to wait for a process to be stopped (SIGSTOP) or resumed (SIGCONT) using boost.asio."

* There was a lot of discussion about the correct way to handle SIGCHILD, and how to implement passing data back and forth between the parent and child processes.

* There was an involved many-sided discussion on about what facilities a Boost.Process library should provide.

* More than one person proposed an alternate interface for the library (Jeff Flinn, Darren Garvey, Max Sobolev, possibly more)

* Brendon Costa expressed concerns that it would be easy to end up with zombie processes using the current library.

* Jeremy Maitin-Shepard felt that "The lack of efficient asynchronous waiting support, and the overly complicated stream behavior interface, are show-stoppers for me".

* Jeff Flinn did not like the lack of launch error reporting (among other things)

-- Marshall Clow; Review Manager