Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

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.

Best,
Vicente