Why does `boost::asio::deadline_timer` allocate a `timer_queue` instance for each `deadline_timer` object?
Hi I am looking into the implementation of `boost::asio::deadline_timer`, based on boost 1.52. As described in [the article on highscore](http://en.highscore.de/cpp/boost/asio.html#asio_extensions), it is implemented in three parts: * `deadline_timer`, the i/o object * `deadline_timer_service`, the service * `detail::deadline_timer_service`, the service implementation There will be a single instance of `deadline_timer_service` serving many `deadline_timer` objects. An instance of `detail::deadline_timer_service` is created for each `deadline_timer` object. Moreover, the timers are scheduled by a scheduler, which is usually a reactor (i.e. `epoll_reactor` on Linux in most cases). There is a `timer_queue_` member of type `timer_queue` in `detail::deadline_timer_service` which is a heap that stores scheduled timers. This means that there will be one instance of `timer_queue` for each `deadline_timer` object. Multiple `timer_queue` objects can be added to the scheduler by `add_timer_queue()`, and they are managed by a class `timer_queue_set`. My question is, why `asio` create multiple queues to handle timers? What is the drawback if we have a single timer queue instance in the scheduler that all timers can share? Please note that I am asking about the `boost::asio::deadline_timer`, not the example in the highscore link. I have posted this question on stackoverflow previously [here](http://stackoverflow.com/q/26922754/930095) -- Best wishes, Wang Danqi
On 11/15/2014 04:24 PM, Wang Danqi wrote:
There will be a single instance of `deadline_timer_service` serving many `deadline_timer` objects. An instance of `detail::deadline_timer_service` is created for each `deadline_timer` object.
All the deadline_timer objects obtain a pointer to the same detail::deadline_time_service (via the basic_io_object constructor) so there is at most one instance per io_service.
I read the code again and find my mistake. The actual relationship is as follows: * `basic_deadline_timer` is the i/o object type, one instance for each deadline_timer; * `deadline_timer_service` is the service type, one per `io_service`, retrieved by the constructor of `basic_io_object`; * `detail::deadline_timer_service` is the service implementation type, one per service, hen one per `io_serive` as well. It is defined as the data member of `deadline_timer_service`; * `detail::deadline_timer_service::implementation_type`: the implementation type of the timer, one per `deadline_timer`. As `timer_queue_` is a member of `detail::deadline_timer_service`, it is one per `io_service` as well. Looks reasonable for me now. The highscore link seems have merged the service implementation type and timer implementation type into one, which is a bit misleading. Thanks. Danqi On Sun, Nov 16, 2014 at 12:58 AM, Bjorn Reese <breese@mail1.stofanet.dk> wrote:
On 11/15/2014 04:24 PM, Wang Danqi wrote:
There will be a single instance of `deadline_timer_service` serving many `deadline_timer` objects. An instance of `detail::deadline_timer_service` is created for each `deadline_timer` object.
All the deadline_timer objects obtain a pointer to the same detail::deadline_time_service (via the basic_io_object constructor) so there is at most one instance per io_service.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Best wishes, Wang Danqi
participants (2)
-
Bjorn Reese -
Wang Danqi