----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40266/#review107959 -----------------------------------------------------------
Overall, it looks good to me. But does the finalizes are called at all in this patch (Probablly just when the system process go down). 3rdparty/libprocess/src/process.cpp (line 735) <https://reviews.apache.org/r/40266/#comment167311> I've been thinking for a while about this mutexes we hold for such a short period of time, that makes me wonder if we actually want to introduce a spinlock mutex for situations like this. - Alexander Rojas On Nov. 20, 2015, 8:19 p.m., Joseph Wu wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/40266/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2015, 8:19 p.m.) > > > Review request for mesos, Artem Harutyunyan and Joris Van Remoortere. > > > Bugs: MESOS-3910 > https://issues.apache.org/jira/browse/MESOS-3910 > > > Repository: mesos > > > Description > ------- > > The `SocketManager` and `ProcessManager` are highly inter-dependent, which > requires some untangling in `process::finalize`. > > * Logic originally found in `~ProcessManager` has been split into > `ProcessManager::finalize` due to what happens during cleanup. > * Some additional cleanup was added for dangling pointers. > * The future from `__s__->accept()` must be explicitly discarded as libevent > does not detect a locally closed socket. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 8fa0594b671969c2713d1b361f2dbbb07d25b3a8 > > Diff: https://reviews.apache.org/r/40266/diff/ > > > Testing > ------- > > `make check` (libev) > `make check` (--enable-libevent --enable-ssl) > > > Thanks, > > Joseph Wu > >
