Boost logo

Boost :

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-15 01:39:19

Le 15/11/12 01:09, Boris Schaeling a écrit :
> On Tue, 13 Nov 2012 20:57:36 +0100, Vicente J. Botet Escriba
> <vicente.botet_at_[hidden]> wrote:
>> [...]Could you then update the documentation so that there are no
>> such dependencies on the underlying platform?
> There are notes referring to boost/process/mitigate.hpp wherever
> #ifdefs are used in the tutorial (the asynchronous waiting example
> excluded). The reason why I didn't use the helpers from that header
> file in the tutorial directly: They don't work necessarily as expected
> in all cases like the rest of the library.
> For instance, while boost::process::pipe_end works for the examples in
> the tutorial it's two different types on POSIX and Windows. And
> Boost.Process makes no guarantee that these two types behave
> consistently on POSIX and Windows (especially not as the types are
> from another Boost library). So I'm trying to make it clear that there
> is a different quality of service: Most features are fully supported,
> 100% cross-platform and safe but a few aren't. And you use these few
> on your own risk. This isn't done to make cross-platform code harder
> to write but to help users to make a conscious decision and avoid
> shooting in their own leg.
> It is of course possible to rearrange the documentation. For instance,
> all examples with asynchronous operations are in that sense
> problematic. They could be removed from the tutorial and put somewhere
> else in the documentation. But I'm not sure whether that makes a
> difference in the end.
IMHO, the documentation must state clearly in a core section what can be
done in a portable way. Then add a non-portable section with each one of
the differences. This will be a first step.

Then of course, I would expect the library makes the last section no
bigger than the fist one ;-)
>> [...]Yes, I see that Boost.Asio has not reached to provide a platform
>> independent abstraction (I'm wondering how this feature appear in the
>> proposal to the standard C++ committe). Any way, could you explain
>> why do you need to use a non portable feature?
> To wait asynchronously on POSIX I use boost::asio::signal_set to
> register a signal handler for SIGCHLD. This is a global setting and
> must be done before a child process is created (actually exits). To
> wait asynchronously on Windows I use
> boost::asio::windows::object_handle to wait on a child process handle.
> This is a per-child setting and can only be done after the child
> process has been created (as only then we have the handle to wait on).
> For a cross-platform solution we would need to merge these two
> concepts somehow: A global setting before child processes are created
> on POSIX and a per-child setting after child processes are created on
> Windows. Here POSIX and Windows are unfortunately totally different.
Couldn't the library store temporarily some data so that the user is not
aware of the difference?
>> [...]You could define a implementation defined native_handle typedef
>> struct child {
>> typedef platform-specific-type native_handle_type;
>> // construct/copy/destruct
>> explicit child(native_handle);
>> native_handle_type native_handle();
>> };
> Would be fine with me. I wish the problems we have to deal with around
> Boost.Process were all like this. ;)
I understand the subject is not easy, but I have the impression that the
portability responsibility has left to the user.


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