Re: [boost] [GSoC] Boost.Process

Subject: Re: [boost] [GSoC] Boost.Process
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-03-25 08:44:19

On Thu, 25 Mar 2010 04:15:05 +0100, Moncef Mechri  
<moncef.mechri_at_[hidden]> wrote:

Hi Moncef,

> [...]I would like to apply as a student for the Boost.Process SoC idea.

you are definitely welcome!

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

I'm not really sure if it's worth doing:
- There are currently so many other problems to think about that I  
wouldn't care about the Executable concept for now.
- Other libraries like Boost.Interprocess simply stick to std::string, too.
- The question how to support different string types and encodings should  
probably be answered by a different library anyway (something like  
Boost.Unicode).

> 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.

In general I don't care where the code ends up as long as it's obvious to  
Boost.Process users that there is code in another library which they might  
want to use. For a possible GSoC project I think we should concentrate on  
Boost.Process only. Discussing with other library maintainers whether we  
can move code to their libraries can still be done later. Then we can  
concentrate on designing and implementing for now (to make sure this  
library is ever finished and reviewed :).

> 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

There is also some signal-related code in Boost.Test (although I have no  
idea if this is something we could use for Boost.Process).

> 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.

I think you describe an asynchronous wait() which is something we  
definitely need. :)

> [...]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

No comment except that creating and managing pipelines is indeed another  
topic we have to think about.

> 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.

I agree it must be changed (adding the macro was a quick fix as  
asynchronous I/O didn't work at all on Windows before).

Boris