On Thu, 10 Feb 2011 19:41:25 +0500, Jeff Flinn
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.