On Tue, 13 Nov 2012 20:57:36 +0100, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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