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: Boris Schaeling (boris_at_[hidden])
Date: 2012-11-14 19:09:18

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.

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

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

Boris