Subject: Re: [boost] [GSoC] Boost.Process
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-03-26 07:37:13
On Fri, 26 Mar 2010 03:58:57 +0100, Moncef Mechri
<moncef.mechri_at_[hidden]> wrote:
> [...]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() ?
From a user's point of view an asynchronous wait() ideally behaves like
any other asynchronous operation supported by Boost.Asio. How the
implementation looks like depends then on the platform (on POSIX systems I
agree we could and maybe have to catch SIGCHLD).
>> [...]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 ?
Yes, no problem (mainly because I'm more concerned about overall design
decisions for now :-).
>> 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
The problem here is that we need an I/O object which needs to be bound to
an I/O service object (not sure how familiar you are with Boost.Asio?).
Now what's the I/O object in Boost.Process? Shall we think of a process as
an I/O object? Can we expect developers to prefer using asynchronous I/O
just as they do with sockets for example? If we don't want to force
developers to create an I/O service object whenever they work with
Boost.Process we need to find another mechanism to turn a process object
into an I/O object later (after it has been constructed). This again is
something which hasn't been done yet in any Boost library (all other
objects support asynchronous I/O right after construction).
I think it all comes down whether we want to treat a process like any
other I/O object. While noone complains about creating I/O service objects
when you use sockets I'm not sure about processes? Developers might be
surprised if Boost.Process is coupled with Boost.Asio?
Boris