----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/70782/#review215728 -----------------------------------------------------------
Looks great, just one last thing. I'm wondering what use the gate has, see my comment below 3rdparty/libprocess/src/tests/process_tests.cpp Lines 2195-2211 (patched) <https://reviews.apache.org/r/70782/#comment302543> I think most of our counting loops use `size_t` so we should probably use that here too instead of `int` for consistency 3rdparty/libprocess/src/tests/process_tests.cpp Lines 2196-2200 (patched) <https://reviews.apache.org/r/70782/#comment302544> Oh, this gate doesn't really accomplish much? I had suggested using it in order to ensure we could fill ProcessA's queue with dispatches, and it accomplished that by preventing ProcessA::initialize() from completing. Did that not work? ``` Promise<Nothing> gate; PID<ProcessA> pid = spawn(new ProcessA(gate.future()), true); for (size_t i = 0; i < 1000; ++i) { dispatch(pid, &ProcessA::f, std::unique_ptr<B>(new B())); } gate.set(Nothing()); ``` - Benjamin Mahler On June 5, 2019, 3:47 p.m., Andrei Sekretenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/70782/ > ----------------------------------------------------------- > > (Updated June 5, 2019, 3:47 p.m.) > > > Review request for mesos, Benjamin Mahler, Chun-Hung Hsiao, and Greg Mann. > > > Bugs: MESOS-9808 > https://issues.apache.org/jira/browse/MESOS-9808 > > > Repository: mesos > > > Description > ------- > > Added a non-deterministic test for MESOS-9808. > > > Diffs > ----- > > 3rdparty/libprocess/src/tests/process_tests.cpp > 05dc5ec2fdc74a989689e4378bef775bcf2b7a87 > > > Diff: https://reviews.apache.org/r/70782/diff/2/ > > > Testing > ------- > > Without any of two fixes from https://reviews.apache.org/r/70778/ - deadlocks > 100 out of 100 times on the hardware I used. > Without the first fix the deadlock is due to the same reason as initially > observed in in MESOS-9808. > > > With both fixes applied, one run takes around 400 ms on a release build. No > deadlock observed in 1000 runs. > > > Thanks, > > Andrei Sekretenko > >
