----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/30808/#review71782 -----------------------------------------------------------
Patch looks great! Reviews applied: [30808] All tests passed. - Mesos ReviewBot On Feb. 10, 2015, 2:22 a.m., Joris Van Remoortere wrote: > > ----------------------------------------------------------- > 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. > > > Bugs: MESOS-2325 > https://issues.apache.org/jira/browse/MESOS-2325 > > > Repository: mesos > > > Description > ------- > > 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 > ----- > > 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 > >
