- 23 Jul, 2016 22 commits
-
-
Juho Snellman authored
- Mix of: - Short term timers that get constantly rescheduled and executed - Long timers that get constantly rescheduled, never executed - Calls to ticks_to_next_event in main time advance loop
-
Juho Snellman authored
- Stop recursing to the outer wheels if the minimum range of the wheel is higher than the maximum acceptable return value.
-
Juho Snellman authored
- When on the core wheel, use time of first event in slot rather than walking through whole chain. (All guaranteed to have same time). - When on the core wheel and processing slot 0, only check outer wheel if slot 0 is empty. (Any events in slot 0 are guaranteed to be scheduled no later than anything on the outer wheel).
-
Juho Snellman authored
-
Juho Snellman authored
-
Juho Snellman authored
-
Juho Snellman authored
- Also fix integer overflow issue in ticks_to_next_event
-
Juho Snellman authored
-
Juho Snellman authored
- Schedules timer in optimized slot, within the provided range - If timeout is already in right range, do nothing. - If timer can be scheduled at a slot boundary such that it does not need to be promoted to another wheel, do that. - In general prefer scheduling as late in the range as possible.
-
Juho Snellman authored
- TimerEvent destructor should cancel timer. - Fix memory leak.
-
Juho Snellman authored
- Add a max parameter (optional), since in my experience you'll never use the ticks of the next event as a raw value.
-
Juho Snellman authored
-
Juho Snellman authored
- The logic there was buggy on anything but the downmost wheel, not taking into account the bitshifting of the tick count. Do the simple thing instead. - Replace the downward hierarchy link with one all the way to the bottom; we now never need to go down just a single layer.
-
Juho Snellman authored
- Then add bizarro workarounds to get it to actually work. But hey, the issue for this has only been open in the bug tracker for 7 years.
-
Juho Snellman authored
- During the timer processing the different wheels could have inconsistent views of time. The proper sequence is to first increment time in all wheels, and then process the timers from starting from the coarsest wheel and finishing with the most granular.
-
Juho Snellman authored
- Mostly for convenience; it's common to cancel timers even if you don't know they are running. Without this, such code would need a lot of (fragile) checks.
-
Juho Snellman authored
- Not enough to just redefine the relink() method, need to also use it...
-
Juho Snellman authored
- No intention of supporting non-hierarchical wheels, so that part of the name was just noise.
-
Juho Snellman authored
-
Juho Snellman authored
- Allows using multiple different callback signatures in the same wheel. - Unfortunately it means having to eat the vtable overhead. - Add a MemberTimerEvent subclass which is initialized with a (dynamic) instance pointer and a (static, templated) member function pointer, instead of just a generic Callable.
-
Juho Snellman authored
-
Juho Snellman authored
-
- 17 Jul, 2016 1 commit
-
-
Juho Snellman authored
-