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