[...]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).
IMHO it is not as complex as it may look like, there already was bunch of possible solutions in this thread. Async wait is very valuable feature.
[...]
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.
I had already suggested that you need a singletone "waiter" thread that would use sigwaitinfo that would allow to do the job for any number of io_services. Note it would even allow to execute installed signal handlers if you need them and notify io_services. asio is very well designed asynchrous event loop that IMHO should be used for any asynchronous operations as it allows to do in "async" way almost any task.
[...]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
See comment above.
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.
It is not straight forward as signal unlike select/epoll/kqueue is process resource and naturally should be handled in single location. But it is notification only issue, Asio provides you event loop that allows dispatch various asynchronous events and it is very valuable and such notifications can be integrated to Asio.
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 don't think that the fact that it is not as straight forward on POSIX platform as on Windows platform you should give up. I come from Unix world and If I was thinking this way then 99% of my project would not support Windows :-) Artyom