Boost logo

Boost :

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.
> IMHO
> it is important to have less features that work then half working
> onces.

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
> purpose.
>
> 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
> returns
> 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.

Comments?

Boris

> [...]


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk