Boost logo

Boost :

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
(for POSIX) and at
(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.


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

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at