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-17 04:36:28

Le 17/11/12 02:33, Boris Schaeling a écrit :
> 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.
I agree. I have not look at the implementation, so that I don't know the 
constraints. I'm just trying to give you some hints on an alternative 
design that could take care of these portability issues. Of course, this 
is not easy, but if at the end the library reach to provide a portable 
interface, you could always provide later platform specific interfaces 
that are more efficient.
>
> 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?
>
You have requested some feedback to your version 0.5. Some of us have 
suggested alternative designs. Don't exploring them before the review 
will postpone the discussion to the short period of the review, which 
IMO is not good.

Best,
Vicente