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: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-02-11 06:14:33

Am 10.02.2011 23:29, schrieb Boris Schaeling:
> 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?

I would vote for incorporating Dimitrys signal-handler into 
boost.process. At the first look I'm not sure if it will work properly 
in a multi-thread env.

I'd like to see the possibility to send signals to the child process too.

posix_child pchild( child);
pchild.signal_sigstop();
pchild.signal_sigcontinue();
etc.

Oliver