Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at