----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18311/#review35015 -----------------------------------------------------------
Looks great! Just a few comments about await(Future) being unnecessary (or just syntactic sugar), discarding futures, and deleting promises. 3rdparty/libprocess/include/process/c++11/collect.hpp <https://reviews.apache.org/r/18311/#comment65432> Do we need this when we have the other calls? s/future1/future/ 3rdparty/libprocess/include/process/c++11/collect.hpp <https://reviews.apache.org/r/18311/#comment65439> In either of these failure cases, should we discard the other futures, like in timedout()? 3rdparty/libprocess/include/process/c++11/collect.hpp <https://reviews.apache.org/r/18311/#comment65440> Would iterator->onAny() work here? 3rdparty/libprocess/include/process/c++11/collect.hpp <https://reviews.apache.org/r/18311/#comment65441> So, await waits for all futures to be ready/failed/discarded, but collect waits for them all to be ready? 3rdparty/libprocess/include/process/c++11/collect.hpp <https://reviews.apache.org/r/18311/#comment65442> s/future1/future/ s/promise1/promise/ 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65392> Why this new API? You've justified the tuple version, but not the single-future version. Or is this for composability? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65429> Why delete the Promise* here? What if the caller were still using it? Can we use shared/owned pointers here to clarify? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65431> Can the compiler automagically convert a Future<T> to a Future<Future<T> >? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65430> Maybe I'm missing something here (Future template magic?), but don't you need to wrap the tuple<Future, Future> if you're going to return a Future<tuple<Future, Future> >? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65424> s/future1/future/ 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65425> s/promise1/promise/ 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65428> Rename variable 'list' to 'futures'? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65391> Can we add something to the comment to clarify that this is actually the 'else' case of (__cplusplus >= 201103L)? - Adam B On Feb. 20, 2014, 7:59 a.m., TILL TOENSHOFF wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18311/ > ----------------------------------------------------------- > > (Updated Feb. 20, 2014, 7:59 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, Ben Mahler, Niklas > Nielsen, and Vinod Kone. > > > Repository: mesos-git > > > Description > ------- > > Currently the Process::await implementation on list<Future>, by the nature of > std::list, expects equally typed futures. This new override implements await > for a tuple of futures, hence allows awaiting differently typed futures in a > single call. > > A C++11 and a boost-based implementation have been added. > > This patch also includes tests on that new feature. > > > Diffs > ----- > > 3rdparty/libprocess/include/process/c++11/collect.hpp PRE-CREATION > 3rdparty/libprocess/include/process/collect.hpp 2a73bc9 > 3rdparty/libprocess/src/tests/process_tests.cpp e899aed > > Diff: https://reviews.apache.org/r/18311/diff/ > > > Testing > ------- > > make check (clang c++11, gcc) > > > Thanks, > > TILL TOENSHOFF > >
