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-16 20:33:24

On Thu, 15 Nov 2012 07:39:19 +0100, Vicente J. Botet Escriba  
<vicente.botet_at_[hidden]> wrote:

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

I'm actually pretty happy with the current solution as I had to create the  
I/O object boost::asio::windows::object_handle first. :) Before that it  
wasn't possible to wait asynchronously on Windows. While we don't have  
cross-platform code unfortunately (still #ifdefs required), we have at  
least cross-platform concepts. And in that sense I'd say another important  
goal has been met: The code is much easier to write and understand than  
having to call POSIX or Windows API functions yourself.

Now it might be possible to build something on top of the Boost.Asio  
classes and like you proposed store temporarily data somewhere. But I'm  
not much further either. If anyone wants to give it a try and write some  
code - drop me a mail.

> [...]I understand the subject is not easy, but I have the impression  
> that the portability responsibility has left to the user.

It's true that depending on your use case the current library can't help  
you to write 100% cross-platform code. I think we are pretty close though.  
More importantly I believe that what the library loses in cross-platform  
ability it easily wins in usability. I wouldn't want to write all that  
low-level code myself what is wrapped by Boost.Process (and partly by  
Boost.Asio). So I associate Boost.Process more with the goal of making C++  
easier to learn and to teach. It would be even easier if no #ifdefs were  
required. But in my opinion 95% cross-platform ability and 100% usability  
is still better than 0% of everything.

Now it could be that the general consensus in the Boost community is that  
a library must be 100% cross-platform in order to be accepted. If that's  
the case and the library is rejected on that ground - no problem for me.  
But the only way to find out is probably going through a review next?

Boris