Unify timer story

[carllerche]

Provide a consistent story around timers. Currently, there is also the tokio-timer crate.

In general, sometimes it is necessary to create timers without knowing about the tokio-core reactor. For example, anything at the Service middleware layer and above should be decoupled from tokio-core.

Also, timer system integrated with epoll should be optimized for usage with a hashed wheel strategy as this is by far the most efficient timer strategy for most network related cases.

That being said, a misconfigured hash wheel has much worse "worse case" performance characteristics than a heap based timer. tokio-timer deals with this by not accepting timeout requests that would trigger this worst case behavior, but I am unsure if a hashed wheel is better as a default than a heap.

I believe that netty provides a hashed wheel timer by default.

[alexcrichton]

I don't personally feel too strongly one way or another which strategy is used by default (wheel or heap) on the event loop, but I'd mostly just prefer that the default usage of the event loop doesn't spawn an extra thread for the timer.

[tailhook]

I don't personally feel too strongly one way or another which strategy is used by default (wheel or heap)

I prefer heap to be used by default. There are few reasons:

1. You can't make good enough random timeouts using wheel
2. You can build a wheel on top of a heap (i.e. one timer in the heap triggers the wheel), I think performance differences should be negligible (but I can't prove it). But not other way around.

If you wonder why would I need random timeouts, there are two use cases off the top of my head:

1. Reconnect timeout for client connections. If you have 1000 client connections on multiple servers and they suddenly fail (say an interface was restarted), it's much better when they are reconnected at random within 100 ms or so
2. Consensus protocols like raft

While second use case is quite niche (still I don't think it requires a thread anyway), the first one should be the default for client connection pools I think, as it avoids load spikes on the server side. This is, for example, how zeromq always works.

[dyatlov]

Wheel timer provides O(1) inserts and deletes.
Heap timer is O(logn) which means that every timer create/removal would lead to some kind of loop. So performance wise I guess that a hash has a better outcome..