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: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-08 17:57:43

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

Hi Vicente,

> 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. :)

> The interface of the setup callback is different so the user will need to
> define two possible setup functions.

Yes.

> [...]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.

> [...]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?

> Could a table of extension be included on the documentation?

Do you mean extension points? Or sample programs like the two above?

Thanks,
Boris