-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/30808/
-----------------------------------------------------------
(Updated Feb. 10, 2015, 2:22 a.m.)
Review request for mesos, Benjamin Hindman, Ben Mahler, Jie Yu, Niklas Nielsen,
and Vinod Kone.
Changes
-------
Removed the change of behavior with regard to paused clock. It seems benh might
have changed this originally to fix an underlying bug.
Used multi-set and single push-pop accounting for outstanding timers.
Bugs: MESOS-2325
https://issues.apache.org/jira/browse/MESOS-2325
Repository: mesos
Description (updated)
-------
1) Maintain an outstanding timers set to prevent scheduling multiple delay
functions for the same timeout.
Ended up moving tick() into the clock namespace to make it more clear that
next() and tick() share this global set of outstanding timers.
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 next()
and tick() rather than pushing it down into the delay_function and management
of ev_timers.
Diffs (updated)
-----
3rdparty/libprocess/src/clock.cpp fcc1eb0b921b3d9b9c033a17e5f6dcecf0a30f08
Diff: https://reviews.apache.org/r/30808/diff/
Testing
-------
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.
Thanks,
Joris Van Remoortere
