----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/37821/#review98329 -----------------------------------------------------------
I've made a few nit comments below but I have some higher-level questions. (1) In this patch, when the destructor of `ProcessManager` is invoked we immediately start to ignore messages. It's not obvious to me that this is necessary or desired. Could we just enqueue the `TerminateEvent` by calling `process::terminate(process, false)`, let it race against other messages that may be coming in, and ignore anything that arrives after `TerminateEvent`? (2) What are the implications of shutting down the event loop via `EventLoop::stop()`? This would be useful to know to learn about the required order between process termination, event loop shutdown, and thread pool joins. 3rdparty/libprocess/src/libev.cpp (line 30) <https://reviews.apache.org/r/37821/#comment154722> Is there a reason why this was moved up? Seems like `async_shutdown` could've been added below this, at its original location? 3rdparty/libprocess/src/process.cpp (line 382) <https://reviews.apache.org/r/37821/#comment154727> The `const` here has no effect. 3rdparty/libprocess/src/process.cpp (lines 442 - 443) <https://reviews.apache.org/r/37821/#comment154755> This fits in 1 line. 3rdparty/libprocess/src/process.cpp (lines 2119 - 2121) <https://reviews.apache.org/r/37821/#comment154823> Could you explain why we want to start ignoring messages here? Below, we do `process::terminate(process, false);` which purposely does not inject the `TerminateEvent` in order to allow the actor to process its queue. This is great, but wouldn't we be dropping messages that were sent between `draining_queue.store(true);` and when the `TerminateEvent` actually gets enqueued at the back? Is the decision that this doesn't matter? 3rdparty/libprocess/src/process.cpp (line 2171) <https://reviews.apache.org/r/37821/#comment154824> `s/int/long/`? - Michael Park On Sept. 8, 2015, 5:54 p.m., Greg Mann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/37821/ > ----------------------------------------------------------- > > (Updated Sept. 8, 2015, 5:54 p.m.) > > > Review request for mesos, Benjamin Hindman, Artem Harutyunyan, Joris Van > Remoortere, Joseph Wu, and Michael Park. > > > Bugs: MESOS-3158 > https://issues.apache.org/jira/browse/MESOS-3158 > > > Repository: mesos > > > Description > ------- > > Join threads in libprocess when shutting down. > > > Diffs > ----- > > 3rdparty/libprocess/src/event_loop.hpp > 36a4cd2b1ff59f6922173ad17115bf80cc3c8f30 > 3rdparty/libprocess/src/libev.cpp 97a2694f9b10bc61841443b21f4f96055493e840 > 3rdparty/libprocess/src/libevent.cpp > ee7906470069b0391dde7cd685b1d4eb3a158c03 > 3rdparty/libprocess/src/process.cpp > 0e5394acff16376809918d583d7aee582cc6da54 > > Diff: https://reviews.apache.org/r/37821/diff/ > > > Testing > ------- > > After configuring with both "../configure" and "../configure > --enable-libevent --enable-ssl": > > make check > > > Also, to check for race conditions related to the initialization/shutdown of > libprocess, try something like: > > for n in {1..1000}; do echo $n; 3rdparty/libprocess/tests > --gtest_filter=ProcessTest.Spawn; done > > > Thanks, > > Greg Mann > >
