----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18950/#review37245 -----------------------------------------------------------
Looks good, two main questions: 1. Will you be following up to remove Sequence? Would love to see it removed if there's no use case. 2. I'd really like to remove internal.hpp, I wonder if: (a) We should wait for C++11 and use std::mutex instead. (b) We should expose a synchronous Mutex in process that wraps std::mutex for C++11 and internal::acquire/internal::release for C++03. (c) We should just live with the cyclic include for now and move acquire/release into mutex.hpp. Forward declare as necessary (similar to what we did in stout/killtree.hpp) Any of these sound good to you? 3rdparty/libprocess/include/process/internal.hpp <https://reviews.apache.org/r/18950/#comment68669> Is the plan to use std::mutex when we have C++11 or to keep these and use std::atomic? If it's the former, would be nice to see a TODO to kill internal.hpp, exposing this header seems really unfortunate. 3rdparty/libprocess/include/process/internal.hpp <https://reviews.apache.org/r/18950/#comment68672> #include <cassert> or <assert.h> (probably we should be consistent with how we do our c library includes. 3rdparty/libprocess/include/process/mutex.hpp <https://reviews.apache.org/r/18950/#comment68670> #include <queue> 3rdparty/libprocess/include/process/mutex.hpp <https://reviews.apache.org/r/18950/#comment68671> #include <stout/memory.hpp>? - Ben Mahler On March 10, 2014, 8:03 a.m., Benjamin Hindman wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18950/ > ----------------------------------------------------------- > > (Updated March 10, 2014, 8:03 a.m.) > > > Review request for mesos, Ben Mahler, Jie Yu, and Vinod Kone. > > > Repository: mesos-git > > > Description > ------- > > This is a simpler alternative to using something like 'Sequence', although it > requires that one explicitly perform an action after the serialized work is > done using something like Future::onAny which now works correctly thanks to > the updated discard semantics. > > > Diffs > ----- > > 3rdparty/libprocess/Makefile.am 3c6219eb6e76306463b3710ab7e50ec8b75d3d76 > 3rdparty/libprocess/include/process/future.hpp > 27b0970bf1d1ae1b977ddfc2de5ee858f1031bf5 > 3rdparty/libprocess/include/process/internal.hpp PRE-CREATION > 3rdparty/libprocess/include/process/mutex.hpp PRE-CREATION > 3rdparty/libprocess/src/tests/mutex_tests.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/18950/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Benjamin Hindman > >
