Re: [boost] [GSoC] Boost.Process

Subject: Re: [boost] [GSoC] Boost.Process
From: Moncef Mechri (moncef.mechri_at_[hidden])
Date: 2010-03-25 22:58:57

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