Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2011-02-11 00:16:55

On Thu, 10 Feb 2011 19:41:25 +0500, Jeff Flinn  
<TriumphSprint2000_at_[hidden]> wrote:

> I've used the process library as a replacement for Qt's QProcess(which
> interfers with the main event loop in our application on Mac OSX). We
> were able to make boost process work across Windows and Mac OSX, but did
> not have that sense of satisfaction at the end that usually comes with
> using most boost libraries.
>
> I do not think the library should be accepted into boost for the
> following reasons.
>
> Problems:
> [Ilya Sokolov: I've reordered some items]

> Still had to create wrapper function and classes and use ifdef's to
> handle platform dependencies in client code.
> Stung multiple times when passing a relative path when setting the
> working directory on unix systems.
> Customization points lack access to many of the required Windows
> CreateProcess arguments.
> Overly complex io specification.

Could you tell us where? Please show also how your library would solve it.

> Lack of synchronicity when launching.
> Pay for process handles even when not used.

Not sure what that means.

> Different semantics regarding success/failure of CreateProcess/exec.
> Lack of launch error reporting.

That could be solved by using a separate pipe for error reporting.
The only library where I've seen this technique is subprocess.py.

> Replication of existing boost library functionality, and functionality
> that better belongs to other libraries.

Where and what functionality, exactly?

> Lots of additional 'stuff' in the header implementing create_child.
> Implementation is obfuscated by all of the ifdef'd platform dependencies
> within a single function.

+1 if you meant operations.hpp

> Lack of separation of concerns in create_child
> The monolithic code lacks ability to properly unit test components.

I'm not sure that the 'separation of concerns' would help us to
unit-test better.

> I started with a fresh slate over the last couple of weeks and have an
> initial high level design of the process launch part that alleviates
> many of the above problems. It's key aspect is that the stock facilities
> themselves are built using the same customization points that client
> code can use to extend the library. Initial high level docs can be
> found at: goo.gl/NvRAH and a rough initial implementation is in the
> attached zip file. This is still very preliminary, but I thought it
> important to add to the discussion now.
>
> Thanks, Jeff

Thank you for the review.