Re: [boost] [process] Arguments and Context concepts

Subject: Re: [boost] [process] Arguments and Context concepts
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-21 02:21:56

----- Original Message ----- 
From: "Boris Schaeling" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 21, 2011 12:01 AM
Subject: Re: [boost] [process] Arguments and Context concepts

> On Thu, 20 Jan 2011 08:21:43 +0100, vicente.botet  
> <vicente.botet_at_[hidden]> wrote:
> 
>> [...]We could have multiple implementations of the same concept and have  
>> just one in a specific platform. In this case we have always the same  
>> class and having a template parameter is not realy useful. If the  
>> requirements are too close to the current context implementation, which  
>> is the advantage to pass Context as template parameter then?
> 
> Indeed, it's questionable if there is an advantage at all. I guess we left  
> the template parameter just in case someone wants to use another type for  
> reasons unknown to us.

Could you document the requirments i nthe reference section?
 
>> What about adding this overloading?
>>
>> template <typename Context>
>> child create_child(const std::string &executable, const Context & ctx);
>>
>> You should need enable_if and some way to recognize if the parameter is  
>> a Context or some Arguments to disambiguate, but  it should be possible,  
>> and this avoids to have an additional args variable when no args at all  
>> are needed.
> 
> Yes, makes sense!

Great. 

>> BTW, are you copying the parameters Arguments and Context now? Why not  
>> pass by reference?
> 
> One goal was to create multiple child processes with the same parameters.  
> While the Arguments parameter is still changed by create_child() I see  
> that Context isn't anymore (probably a side effect of another change to  
> the context class when we redesigned the way streams are configured).

Then you could pass Context by cont& without any change on user code. You could commeback to pass by value if you need to modify it.

>> A see the change to the working directory as a really specific case.  I  
>> would pass it as an argument to the process creation and let the child  
>> process make itself the change to the working directory. Could you tell  
>> us why did you need to added it?
> 
> Well, you might not have access to the source code for example and can't  
> make the child process change the working directory. 

This is too specific to be included in a Process library.

> A more important  
> reason is though that I'd describe Boost.Process as a library trying to  
> support as many high-level cross-platform concepts as possible. I guess  
> that's the current goal after we gave up other ideas like trying to  
> support as many platform-specific features as possible (that was when we  
> had POSIX and Windows classes which could have grown endlessly and would  
> still never have been complete; now we have extension points to provide  
> the flexibility of using platform-specific features).

I don't find the answer to my question here.
 
>> An alternative to multiple overloading could be to use the essence  
>> pattern of a child process creation and pass to the function a single  
>> parametter:
>>
>> child create_child(const creation_essence & );
> 
> In my opinion our current context class is rather small that this isn't  
> required (it was much worse before when we had POSIX and Windows context  
> classes). I think something like this would help if the context class grew  
> again. This again depends on high-level cross-platform concepts we might  
> be able to identify to describe a process context. But if you look at  
> things like uid on POSIX or SECURITY_ATTRIBUTES on Windows it's rather  
> difficult to imagine how high-level cross-platform concepts could look  
> like to support these things in Boost.Process. It looks like context is  
> already pretty much complete.

The same interface arguments applies to the Context concept independently of whether you use an essence argument. If you require a more high level interface for the Context concept, you will be able to implement it as efficiente as posible on specific platforms. The current concept behind the Context parameter has a user interface that is not enough abstract. The use of specific fields depending on std::string forbids any possible optimisation.

Best,
Vicente