Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-09-11 17:47:49

On Sat, 11 Sep 2010 22:51:25 +0200, Jeremy Maitin-Shepard  
<jeremy_at_[hidden]> wrote:

> On 09/11/2010 01:32 PM, Boris Schaeling wrote:
>> Indeed. But as context doesn't support arbitrary file descriptors those
>> must be configured differently anyway.
>
> I'm suggesting that it should.  From the library's perspective, there is  
> no difference between configuring the child's file descriptors 0, 1, and  
> 2, and configuring any other file descriptors, at least on POSIX, and  
> given that it is useful for the user, it might as well be exposed.  (Of  
> course, on Windows, things are different, but I think you have just as  
> elegant an interface and still allow this flexibility for POSIX while  
> retaining portable syntax.)

I'm not really convinced of adding platform-specific features. We had  
POSIX- and Windows-only classes and functions in previous versions of the  
library (in fact that's how my Boost.Process version 0.3 looked like). The  
implementation of the new version is by far less bloated and much cleaner.

But maybe we can add another extension point? In fact it's not required to  
subclass context as create_child() is a function template. You can create  
another context class with new member variables and pass it to  
create_child(). The question is then what exactly would the extension  
point need to look like and how would it differ from context::setup()  
which is already provided today?

>> Please have a look at
>> <http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/example/file_descriptors_setup.cpp>.
>> There are two pipes used to create file descriptors 3 and 4 which should
>> be inherited by the child process. As the pipe stream behavior is used
>> explicitly the user knows if 3 and 4 should be read or write ends of the
>> pipe. The user can pass the information to the pipe stream behavior
>> while the context indeed can't (in this example there is still a boolean
>> value used).
>
> I saw that example, but it hardly seemed like a very good exposition of  
> the convenience provided by the library.  (Also, as I alluded to in some

I agree. It's a bit strange to use stream behaviors like this. But then  
stream behaviors were really invented to create a platform-independent way  
of configuring standard streams and not to support platform-specific  
features.

> of my other example code snippets and as has been discussed a bit by  
> others, I think that using an std::pair as the return value for those  
> type of things is a bad idea.  Instead, read_end and write_end, or  
> parent_end and child_end, depending on the situation, should be used.)

We need both ends in create_child() as the function returns a child  
object. It is the one used by the parent process to possibly communicate  
with the child process: One end is passed to the child process and the  
other end remains in the parent process so it can communicate with the  
child process.

Boris