On Mon, 07 Feb 2011 23:26:57 +0100, Vicente Botet <vicente.botet@wanadoo.fr> 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/exampl... (for POSIX) and at https://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/exampl... (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