Re: [boost] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

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

> [...]