[boost] [GSoC] Boost.Process

Subject: [boost] [GSoC] Boost.Process
From: Moncef Mechri (moncef.mechri_at_[hidden])
Date: 2010-03-24 23:15:05

Hi boosters,

My name is Moncef Mechri (aka "fireboot" on IRC). I'm a 20 years old french
student in my final undergraduate year at the Faculté des Sciences de
Luminy, Marseille, France.
I would like to apply as a student for the Boost.Process SoC idea.

My main domains of interest include C and C++ programming languages, system
programming (especially on POSIX systems), parallel computing, generic
programming, object-oriented design, software optimizations, graph theory,
and UI development (using Qt). So far I've used a couple of boost librairies
: Boost.Thread, Boost.Random, some features from Boost.Interprocess
(principally atomic operations), Boost.SmartPointers, Boost.Foreach and
Boost.Bind. They were all a pleasure to use and it's why I've just written a
(french) paper about one of them : Boost.thread [1].
I'll would be glad to help improving the set of high quality libraries that
Boost is.

I have some ideas to help finishing Boost.Process and I'd be happy to hear
your opinions about them:

1) Abstract the string type used to name executables. This could be done for
example using a traits class

2) Move find_executable_in_path() and executable_to_progname() to
Boost.Filesystem. I think their job is filesystem-related so maybe it would
be wise to move them accordingly.

3) On POSIX systems, provide raise(3) and kill(3) functions to respectively
send a signal to the current process and send a signal to a child. Sending
signals to unrelated process should probably not take place in Boost.Process
but rather in Boost.Interprocess

4) On POSIX systems, when a process dies it becomes a zombie process until
wait() is called. Since wait() blocks, things may become tricky if there are
a lot of child process. When a process die, the SIGCHLD signal is sent to
his creator. It might be nice to use that by setting up a SIGCHLD signal
handler which calls wait() when this signal is received.
Since a similar problem exists on Windows, Boost.Process should provide a
similar solution on this platform, but I've not yet thought about a possible
design for it.
It might be also useful to provide a way to activate/deactivate this
feature, for example with a macro BOOST_MANAGES_DEAD_PROCESS

5) Right now, boost::process::wait_children() returns the first exit code
which is not equal to EXIT_SUCCESS, and if there are more than one process
which finished abnormally, return values of those child processes are
ignored. I think we could improve that by returning for example a
vector<boost::process::status> instead of just one boost::process::status.
Doing that, we can retrieve all the status codes.
It might be useful to define a way to toggle on/off

6) Actually in Boost.Process, if the developer wants to be able to do
asynchronous operations on Windows he has to define the
BOOST_PROCESS_WINDOWS_USE_NAMED_PIPE macro. By doing so, it makes
Boost.Process on Windows create named pipe for all streams even if
asynchronous operations are not used in all of them.
First of all I propose to add a boost::process::anonymous_pipe class to
Boost.Process, and a boost::process::named_pipe class to Boost.Interprocess
(because named pipe can be used between unrelated process).
After that the developer should be able to choose between anonymous pipe or
named pipe on a per-stream basis (but of course asynchronous operations will
only work on streams using named pipes).

Thanks for reading, it'd be nice if someone accept to comment my ideas

Moncef Mechri.

[1] http://fz-corp.net/?p=505