Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Roland Bock (rbock_at_[hidden])
Date: 2012-08-18 17:54:24

On 2012-08-18 17:31, Boris Schaeling wrote:
> Boost.Process 0.5 has been released! Documentation and library can be
> found at: <http://www.highscore.de/boost/process0.5/>
Hi,

it is really good to see that this project is continued! Thanks for the
effort! Just two weeks ago I needed something like this: Start a child
process (shell script in my case), feed it some data via STDIN, read
whatever it sends to STDOUT or STDERR, with timeouts and size limits. So
basically, your tutorial fits perfectly and I certainly would have used
boost::process if it were a boost library already :-)

After reading the tutorial and taking a quick look at some of the
reference pages, my only concern is that I see blocks like these too
often for my taste:

#if defined(BOOST_WINDOWS_API)
...
#elif defined(BOOST_POSIX_API)
...
#endif

It is probably good that it is possible to get down to the dirty system
specific details if required, but I'd like to be able to handle child
processes without thinking about the operating system (unless I want to
do something really special).

For instance, I like the inherit_env initializer. Does something on
POSIX, probably a no-op on Windows. I can just use it and be done with
the environment.

But things like wait_for_exit seem strange to me: If the library takes
care of the forking and handles setting up pipes in such a nice way, why
should the user of the library be bothered with the different ways of
interpreting the exit information (unless he really, really wants to)?

Same with a /dev/null sink. Offering a factory method would be easy and
spares the user.

Or this one:

#if defined(BOOST_POSIX_API)
    signal(SIGCHLD, SIG_IGN);
#endif
    child c = execute(run_exe("test.exe"));
#if defined(BOOST_WINDOWS_API)
    c.discard();
#endif

I understand that the signal stuff is not required for Windows, but why
not offer a convenience function that sets the signal handler on POSIX
and does nothing on Windows?

Same with the discard method. Does something on Windows, does nothing on
POSIX, and I get to write code without using the #ifdefs every other line.

The other thing about the discard: I think one of the first things I'd
do is write a wrapper for child that is non-copyable (as also suggested
by Joel) and calls discard in its destructor. I wonder if that should
not be part of the library, too?

With the probable exception of the asynchronous IO and wait, I think it
should be possible to get rid of the #ifdefs in the tutorial. And IMHO
that would be a nice improvement for what looks like a cool library
already :-)

Regards,

Roland