Re: [boost] [GSoC] Boost.Process

Subject: Re: [boost] [GSoC] Boost.Process
From: Bruno Santos (bsantos_at_[hidden])
Date: 2010-03-26 08:35:53

Hi,

Boris Schaeling wrote:
> 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).
> 

The IO Service for Boost.Process would have to create a thread to handle
the signals. However, I think the Boost.ASIO implementation details
already does something to block signals, this cannot be ignored! Anyway,
see *sigemptyset*, *sigaddset* and *sigwait*. This API's allows us to
handle signals in a sane manner :)

>
> 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
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost