Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2011-02-08 18:23:55

Boris Schaeling wrote:
> 
> On Mon, 07 Feb 2011 23:26:57 +0100, Vicente Botet  
> <vicente.botet_at_[hidden]> wrote:
> 
> Hi Vicente,
> 

Hi Boris,

>> I want to discuss here of how transparent would be the user code to be  
>> able
>> to use non portable extension with the current interface. The way  
>> extensions
>> are provided means that a user needs to use the BOOST_POSIX_API,
>> BOOST_WINDOWS_API in his own code when he uses an extension. Could the
>> documentation include some explicitly examples.
> 
> there is an example at  
> https://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/example/chroot_setup.cpp  
> (for POSIX) and at  
> https://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/example/startupinfo_setup.cpp  
> (for Windows). If the documentation doesn't refer to them clearly I'll  
> have to improve it. :)
> 

I was looking for an example of portable code that uses the two functions.
That is merge the two examples in one.

>> [...]Note that these setup functions are called on a different context  
>> either on
>> the child either on the parent process, but both will be assigned to the
>> same context field.
> 
> True (and it's good that you noticed; that makes me think the  
> documentation is not that bad :).
> 
>> Any setting of the ctx.streams with fd >2 should be protected
>>
>> ctx.streams[3] = ...
>>
>> While the preceding code doesn't have any sens under WINDOWS, the library
>> don't provide an interface that forbids it, but the current  
>> implementation
>> just ignore it. I'm not sure if this is good in this case as the  
>> application
>> could not work in the same way in POSIX or WINDOWS systems. If the class
>> stream_id I proposed in this thread is used as domain of the map, the  
>> code
>> will not compile as a stream_id cannot be constructed from fd>2 on  
>> WINDOWS.
> 
> I have to read your other email still. The operator[] is rather new  
> though. We had three get functions before to access the handles for stdin,  
> stdout and stderr of the child process. I had argued that these are the  
> only cross-platform streams. However the counter-argument was that there  
> was no way to pass fds > 2 to a child process on POSIX - not even with an  
> extension point. Developers would need to look for another library to do  
> that. So we tried to create an interface which would make sense for  
> Windows developers and would provide developers on POSIX the flexibility  
> they need. That's how we got here.
> 

Thanks for the exlanation. I was aware by reading the thread of
september-october :)

>> [...]Instead of just defining them for POSIX
>>
>> #if defined(BOOST_POSIX_API)
>>     pipe()  : stype_(unknown_stream)  { }
>>     pipe(stream_type stype) : stype_(stype)  { }
>> #endif
>>
>> You can add the respective constructors for WINDOWS, even if the  
>> parameter
>> is completely ignored.
>>
>> #if defined(BOOST_WINDOWS_API)
>>     pipe() { }
>>     pipe(stream_type /*stype*/)  {    }
>> #endif
>>
>> The same applies to all the behaviors using stream_type.
> 
> The use case would be to create a stand-alone pipe outside of  
> Boost.Process? If so I wonder whether we should (additionally?) provide  
> something else than stream behaviors. They are pretty much tailored for  
> Boost.Process. I'm fine with making the constructors available on all  
> platforms. But it's not nice that you get a stream_ends object with a  
> parent and child end when you actually want to create a pipe with a read  
> and write end?
> 

Yes this exactly why I was proposing that these constructors must be
protected and used only by the implementation as the correct use can be
possible as undocumented. Read on the other post.

>> Could a table of extension be included on the documentation?
> 
> Do you mean extension points? Or sample programs like the two above?
> 

Extension points. As Doxigen don't allows to show it in the synopsis, a
table showing the specific extensions points will help.

Best,
Vicente

-- 
View this message in context: http://boost.2283326.n4.nabble.com/Subject-Formal-Review-of-Proposed-Boost-Process-library-starts-tomorrow-tp3263607p3283561.html
Sent from the Boost - Dev mailing list archive at Nabble.com.