On Thu, 25 Mar 2010 04:15:05 +0100, Moncef Mechri <moncef.mechri@gmail.com> 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