Subject: Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Boris Schaeling (boris_at_[hidden])
Date: 2011-02-10 17:29:38
On Thu, 10 Feb 2011 06:49:36 +0100, Artyom <artyomtnk_at_[hidden]> wrote:
> [...]I think if you can't implement this properly just don't implement.
> it is important to have less features that work then half working
I agree (although for a different but somehow related reason; the
complexity of the implementation bothers me more).
>> However I don't think using SIGCHLD is a good idea.
>> As a library developer I don't really want to steal the
>> signal handler for any signals as we have no idea if there
>> are other parts in a program which actually wait for SIGCHLD, too.
> SIGCHLD is used for wait operation on the child to exit, it is its
> So it is better to state in the documentation that it uses SIGCHLD
> then to say that
> a) Only one io_service can do async waiting
You have the same problem with a SIGCHLD-based implementation. If an
io_service installs a signal handler you can't use a second io_service as
it would install a new signal handler.
> Also you don't have to steal the handler you can call it (sigaction
> previous handler).
>> We don't know either if the signal handler is reset after we set it.
> No it is not. It is basic knowledge about POSIX/Unix programming.
I think we misunderstand each other here. But Robert and Jeremy have
already expressed what I tried to say.
> [...]I think if you state this clearly in documentation it is OK as
> SIGCLD is "Unix" way to wait for child.
Here's a new proposal:
We remove boost::process::status. While it's tempting to use Boost.Asio I
come to the conclusion that it isn't and can't be the framework of choice
for all asynchronous operations. When I think about my attempts to create
a Boost.Asio extension to handle signals I feel only confirmed.
However my similarly complicated signal handler was based on a clean
implementation from Dmitry Goncharov. He had tried to create a Boost.Asio
extension which was never added to Boost.Asio though - probably because
his I/O object doesn't work and look like all the others. But then why not
adding it to Boost.Process?
Dmitry's code can be found at https://svn.boost.org/trac/boost/ticket/2879
(it's only two header files). It needs an io_service object but that's all
what it has in common with other I/O objects. His code would not only make
it possible to wait for child processes but handle all signals.
Then Boost.Process would give up the goal of supporting only
cross-platform features. But if I had to choose between the current
implementation of boost::process::status, a library with no support at all
to wait for child processes and a non-asio-like class to handle signals
I'd choose the latter.
I'm not so sure what we should do on Windows. Maybe boost::process::status
should not be dropped completely as Windows developers might want to use
it. If anyone knows whether it's possible to wait for a child process on
Windows using existing Boost.Asio services the implementation could be
simplified a lot.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk