> On Feb. 24, 2016, 9:17 p.m., Alexander Rojas wrote: > > src/tests/hierarchical_allocator_tests.cpp, lines 2395-2398 > > <https://reviews.apache.org/r/43879/diff/5/?file=1268385#file1268385line2395> > > > > Why isn't it an `AWAIT_READY` macro? you still use an `AWAIT_*` > > afterwards, so I doubt is the result value.
I want to *return* a `None` here if the response does not become ready while the macros you suggest do not return the correct type (`void` instead of `Option<T>`). - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/43879/#review120570 ----------------------------------------------------------- On Feb. 24, 2016, 9:42 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/43879/ > ----------------------------------------------------------- > > (Updated Feb. 24, 2016, 9:42 p.m.) > > > Review request for mesos, Alexander Rukletsov and Ben Mahler. > > > Bugs: MESOS-4718 > https://issues.apache.org/jira/browse/MESOS-4718 > > > Repository: mesos > > > Description > ------- > > Added allocator metrics for number of allocations made. > > > Diffs > ----- > > src/master/allocator/mesos/hierarchical.hpp > 3043888630b066505410d3b32c5b3f813cc458c1 > src/master/allocator/mesos/hierarchical.cpp > 5ef29f26ec8071f79c2f4f78dbe2bb0a613cc92d > src/tests/hierarchical_allocator_tests.cpp > 5f771f02db9bd098f3cd36730cd84bf2f5e87a33 > > Diff: https://reviews.apache.org/r/43879/diff/ > > > Testing > ------- > > make check (OS X) > > I confirmed that this does not lead to general performance regressions in the > allocator; this is partially expected since the added code only inserts > metrics in the allocator while the actual work is perform asynchronously. > These tests where performed with > `HierarchicalAllocator_BENCHMARK_Test.DeclineOffers` on an optimized build > under OS X using clang(trunk) as compiler. > > > Thanks, > > Benjamin Bannier > >