Philipe, thanks for your notification !
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).
You're probably right, it's probably not the bigger problem to care about and it probably doesn't worth it.
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).
Thanks for the info; I'm going to check what signal-related code Boost.test has. Moreover, I don't think Boost.Process should provide platform-independent signals mechanisms, since Windows only supports ANSI signals (which are very (very very) limited).
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. :)
Yeah :). What do you think about the idea to set up an handler which calls wait() when a SIGCHLD signal is received ? Otherwise, what's your vision of this asynchronous wait() ?
[...]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.
This means that you're ok with this proposition ?
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).
I'm going to thing about a concrete proposition to solve this issue Have you any other suggestions ? Thanks for your answer Boris :) Moncef Mechri