-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30808/
-----------------------------------------------------------
(Updated Feb. 12, 2015, 11:14 p.m.)
Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas Nielsen,
and Vinod Kone.
Changes
-------
Re-organized so that we keep next() simple, and wrap it with scheduleNext().
Used a stack to represent the cached scheduled timeouts.
Invalidate the cache when we advance / update the clock so we force a
recalculation of the duration of the timeouts.
Bugs: MESOS-2325
https://issues.apache.org/jira/browse/MESOS-2325
Repository: mesos
Description (updated)
-------
1) Maintain an outstanding timers stack to prevent scheduling multiple delay
functions for the same timeout.
Ended up moving tick() into the clock namespace to make it more clear that
scheduleNext() and tick() share this global stack of outstanding timeouts.
The original behavior used a single timer and adjusted the timeout. We didn't
go back to this as benh wanted a generalized way to delay an arbitrary
function. Therefore we handle the maintenance of this optimization in
scheduleNext() and tick() rather than pushing it down into the delay_function
and management of ev_timers.
Diffs (updated)
-----
3rdparty/libprocess/src/clock.cpp b92d5de2631986506361e28c05cb6169e6632a70
Diff: https://reviews.apache.org/r/30808/diff/
Testing (updated)
-------
make check
A worst-case scenario test for the example listed in MESOS-2325. Constructed
many timers in decrementing time (i.e. 500, 499,498, etc.). CPU utilization
during this test went down greatly and is on par with code prior to the clock
refactoring changes.
Ran this test with 25K timers, with 10 firing every millisecond. ~3% cpu usage
on a macbook.
Thanks,
Joris Van Remoortere
