----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/27925/#review61064 -----------------------------------------------------------
3rdparty/libprocess/src/process.cpp <https://reviews.apache.org/r/27925/#comment102515> do we expect public SocketManager calls to be called from other public SocketManager calls? Can we change the design such that the public methods lock and have private implementations that assume the lock is held? Then we can just use a simple mutex instead. It also means we can more easily reason about the code: public APIs are always called with the mutex unlocked is an invariant. 3rdparty/libprocess/src/synchronized.hpp <https://reviews.apache.org/r/27925/#comment102516> do we still need these at all? if we can use std::mutex and std::lock_guard, why do we need this construct? - Dominic Hamon On Nov. 12, 2014, 12:32 p.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/27925/ > ----------------------------------------------------------- > > (Updated Nov. 12, 2014, 12:32 p.m.) > > > Review request for mesos, Dominic Hamon and Joris Van Remoortere. > > > Repository: mesos-git > > > Description > ------- > > Updates 'synchronized' to use std::mutex and std::recursive_mutex instead of > having to set up a 'synchronizer' and 'synchronizable'. > > NOTE: Tha manual template expansion in synchronized.hpp can be eliminated but > this was just a quick POC. > > > Diffs > ----- > > 3rdparty/libprocess/src/process.cpp > 85fb9958342f0bcdde322d9c55333126e6f86668 > 3rdparty/libprocess/src/synchronized.hpp > 6a341b851d516bcecb2f893fbb5d08a769b09b3a > > Diff: https://reviews.apache.org/r/27925/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
