> On Nov. 25, 2015, 2:30 a.m., Alexander Rojas wrote:
> > 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).

As of this patch, `process::finalize` is only called once at the end of the 
libprocess tests (3rdparty/libprocess/src/tests/main.cpp).

For tests later on (when `process::reinitialize` was finished), I did insert 
`process::reinitialize` between every `MesosTest`.


> On Nov. 25, 2015, 2:30 a.m., Alexander Rojas wrote:
> > 3rdparty/libprocess/src/process.cpp, line 735
> > <https://reviews.apache.org/r/40266/diff/1/?file=1134919#file1134919line735>
> >
> >     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.

Good point.  We could follow the reasoning behind `process::initialize` 's 
locks.


- Joseph


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


On Nov. 20, 2015, 11:19 a.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/40266/
> -----------------------------------------------------------
> 
> (Updated Nov. 20, 2015, 11:19 a.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
> 
>

Reply via email to