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.
> 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
(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, gregod at, cpdaniel at, john at