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
>> 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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk