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: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-10 19:30:32

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

Hi Jeff,

> [...]Problems:
> 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.
> Different semantics regarding success/failure of CreateProcess/exec.
> Lack of synchronicity when launching.
> Lack of launch error reporting.
> Replication of existing boost library functionality, and functionality
> that better belongs to other libraries.
> Lots of additional 'stuff' in the header implementing create_child.
> Pay for process handles even when not used.
> Overly complex io specification.
> Customization points lack access to many of the required Windows
> CreateProcess arguments.
> Implementation is obfuscated by all of the ifdef'd platform dependencies
> within a single function.
> Lack of separation of concerns in create_child
> The monolithic code lacks ability to properly unit test components.
>
> 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, it's always interesting to see new approaches. Looking at your  
documentation and code I'd say that you basically turned the context class  
and create_child() function into an executor concept and class? I think I  
can see how this helps to break up the monolithic code in create_child().  
However I would be interested to see how this works in practice. I wonder  
how much I would need to learn about the concepts of the library and how  
much code I would need to write to customize the executor that I wouldn't  
simply call CreateProcess() myself. :)

I'm also not sure whether your approach solves the problems you listed  
above. For example if you introduce platform-specific classes you have to  
use #ifdefs even more? The very first versions of Boost.Process actually  
contained generic, POSIX and Windows classes. Unless you used the generic  
version it felt like using two different libraries. The idea of using one  
class for everyone plus extension points is to minimize the code you have  
to write and maintain if you would like to use a certain platform-specific  
feature.

What do you mean with "Pay for process handles even when not used"? You  
can discard the return value of create_child(). If you want the process  
handle to be discarded even earlier I wonder whether you aim for a  
different goal. You want as much flexibility with Boost.Process as you  
have when using system functions directly?

I'm also interested in what you mean with "Overly complex io  
specification". Is this about stream behaviors?

Thanks,
Boris