----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/65679/#review199223 -----------------------------------------------------------
src/tests/slave_tests.cpp Lines 4158-4160 (patched) <https://reviews.apache.org/r/65679/#comment279523> Can we do the following: ``` EXPECT_CALL(sched, executorLost(...)) .Times(AtMost(1)); ``` And remove `executorLost`, since it's not in the original test? src/tests/slave_tests.cpp Lines 4671 (patched) <https://reviews.apache.org/r/65679/#comment279526> Since we dispatch `unmocked__run` into the slave context, we can just leave the `FutureSatisfy` as is, to be consistent with other tests. src/tests/slave_tests.cpp Lines 4863-4865 (patched) <https://reviews.apache.org/r/65679/#comment279524> Ditto. src/tests/slave_tests.cpp Lines 4986-4988 (patched) <https://reviews.apache.org/r/65679/#comment279525> Ditto. src/tests/slave_tests.cpp Line 4982 (original), 5022 (patched) <https://reviews.apache.org/r/65679/#comment279527> Is it guaranteed that this lambda will finish before `exitedExecutorMessage` is satisfied, so we can make sure that is function won't be called after the variables are destructed? If not, we probably should do the following instead: ``` Future<Nothing> unmocked___run = process::dispatch(slave.get()->pid, [&] { slave.get()->mock()->unmocked___run( ...); return Nothing(); }); ``` And do `AWAIT_READY(unmocked___run)` at the end of the test. src/tests/slave_tests.cpp Lines 5179 (patched) <https://reviews.apache.org/r/65679/#comment279522> Is it guaranteed that this lambda will finish before `executorShutdown` is satisfied, so we can make sure that is function won't be called after the variables are destructed? If not, we need to do the same thing I suggested above. src/tests/slave_tests.cpp Lines 5382-5389 (original), 5431-5443 (patched) <https://reviews.apache.org/r/65679/#comment279533> The high-level guideline is try to avoid using/exposing `Promise` unless necessary. Let's return a `Nothing` in the lambda instead, as I suggested above. - Chun-Hung Hsiao On Feb. 16, 2018, 1:22 a.m., Meng Zhu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/65679/ > ----------------------------------------------------------- > > (Updated Feb. 16, 2018, 1:22 a.m.) > > > Review request for mesos, Chun-Hung Hsiao and Greg Mann. > > > Bugs: MESOS-8611 > https://issues.apache.org/jira/browse/MESOS-8611 > > > Repository: mesos > > > Description > ------- > > Directly invoking unmock calls in the test process can potentially > cause races with the real mock slave process. It is more robust to > dispatch the unmock calls to the real mock slave process. > > Also added several mock expectations to avoid "uninteresting mock > call" test warnings. > > > Diffs > ----- > > src/tests/slave_tests.cpp e253317a67019302f18afe11e2a314e716cec226 > > > Diff: https://reviews.apache.org/r/65679/diff/4/ > > > Testing > ------- > > `./bin/mesos-tests.sh --gtest_filter=*SlaveTest* --gtest_repeat=-1 > --gtest_break_on_failure` runs forever :) > > > Thanks, > > Meng Zhu > >
