> On April 13, 2016, 9:27 a.m., Alexander Rukletsov wrote:
> > src/tests/master_allocator_tests.cpp, line 1604
> > <https://reviews.apache.org/r/46135/diff/1/?file=1342280#file1342280line1604>
> >
> >     If you're not doing any checks with resources, you can use 
> > `Future<Nothing>` instead.
> 
> Yongqiao Wang wrote:
>     They are different variable type, 'const mesos::Resources' can not 
> convert to 'const Nothing'.

You use `Future<Nothing>` together with `FutureSatisfy`. The difference between 
`FutureArg` and `FutureSatisfy` is that the latter sets the future when the 
method is invoked, while the former _additionally_ saves the actual value of 
some argument. If you don't use this value later on, you don't have to use 
`FutureArg`.


> On April 13, 2016, 9:27 a.m., Alexander Rukletsov wrote:
> > src/tests/master_allocator_tests.cpp, line 1637
> > <https://reviews.apache.org/r/46135/diff/1/?file=1342280#file1342280line1637>
> >
> >     You don't need this `settle()`.
> 
> Yongqiao Wang wrote:
>     According to my understanding, call Clock::settle() after 
> Clock::advance(), then it can ensure allocate() is executed before do the 
> following check. So I think it is needed.

`AWAIT_READY` does that for you if the clock is paused.

Quoting BenM:
"Think about it this way, if you put a `settle()` before the `AWAIT_READY`, 
then the implication is that you don't need `AWAIT_READY` at all, you could 
just do `ASSERT_TRUE(f.isReady())` because you've done the necessary settling 
explicitly. This is why it seems strange to have a `settle` immediately preceed 
an `AWAIT_READY`, its the job of `AWAIT_READY` to wait until the future is 
ready (which means doing the right thing when the clock is paused, otherwise we 
would have to write a lot of `settle` calls)."


- Alexander


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46135/#review128640
-----------------------------------------------------------


On April 13, 2016, 3:21 a.m., Yongqiao Wang wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46135/
> -----------------------------------------------------------
> 
> (Updated April 13, 2016, 3:21 a.m.)
> 
> 
> Review request for mesos, Adam B and Alexander Rukletsov.
> 
> 
> Bugs: MESOS-5146
>     https://issues.apache.org/jira/browse/MESOS-5146
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Pause the clock and make sure all resources from rescinded
> offers are recovered before doing a batch allocation.
> 
> 
> Diffs
> -----
> 
>   src/tests/master_allocator_tests.cpp 
> 404ff098baf89bf2a1c6e32424d591a6ea1a093c 
> 
> Diff: https://reviews.apache.org/r/46135/diff/
> 
> 
> Testing
> -------
> 
> Make && Make check.
> 
> ```
> Yongs-MacBook-Pro:build yqwyq$ ./src/mesos-tests 
> --gtest_filter=MasterAllocatorTest/0.RebalancedForUpdatedWeights
> [==========] Running 1 test from 1 test case.
> [----------] Global test environment set-up.
> [----------] 1 test from MasterAllocatorTest/0, where TypeParam = 
> mesos::internal::master::allocator::MesosAllocator<mesos::internal::master::allocator::HierarchicalAllocatorProcess<mesos::internal::master::allocator::DRFSorter,
>  mesos::internal::master::allocator::DRFSorter, 
> mesos::internal::master::allocator::DRFSorter> >
> [ RUN      ] MasterAllocatorTest/0.RebalancedForUpdatedWeights
> [       OK ] MasterAllocatorTest/0.RebalancedForUpdatedWeights (385 ms)
> [----------] 1 test from MasterAllocatorTest/0 (386 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 1 test from 1 test case ran. (396 ms total)
> [  PASSED  ] 1 test.
> 
> ```
> 
> 
> Thanks,
> 
> Yongqiao Wang
> 
>

Reply via email to