On Thu, 10 Feb 2011 06:49:36 +0100, Artyom <artyomtnk@yahoo.com> 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
[...]