On 02/11/2011 04:34 PM, Boris Schaeling wrote:
On Fri, 11 Feb 2011 08:07:34 +0100, Artyom <artyomtnk@yahoo.com> wrote:
[...]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.
This was exactly what I always thought, too. Now I believe that I made the classic mistake of seeing everywhere nails because of the Boost.Asio hammer. As much as I like Boost.Asio I don't think anymore that we should try to integrate everything in Boost.Asio just because we managed to add the word "asynchronous" to the description of a feature. There are certain requirements, and if they are not met I think Boost.Asio is the wrong answer.
Boost.Asio is based on I/O service objects which provide services to I/O objects. If we create a singleton outside of I/O service objects what's their purpose? We don't need them anymore. We could use the singleton directly. That's what Dmitry Goncharov had proposed with his signal_handler.
Or let's imagine Boost.Asio wouldn't exist and we would think about a signal handler. Everyone would probably agree that we need a singleton. But would anyone argue that we also need an I/O service object and an I/O object?
Given the easy to use Boost.Asio API some developers would still prefer to use it. And it could all still be built on top of such a singleton. I, for one, would always prefer direct access to the singleton though - especially if it's that easy to use as Dmitry's and Boost.Asio can't provide me anything extra.
If a dedicated thread is used to handle SIGCHLD, then that thread could also invoke the asynchronous notifications, and Boost Asio wouldn't add anything. However, users may instead wish to not use a dedicated thread, or to receive notifications in a different thread, in which case Boost Asio would seem to have some use.