----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18311/#review35318 -----------------------------------------------------------
Looks better all in one file; feels like less duplication. Lingering concern about discarded futures. 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65781> What if future.isPending/isDiscarded/isFailed? Should this really be onAny()? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65782> You set the return type on the .then lambda for Future<Future<T>>, but don't need to set it here? Why is it needed in one but not the other? 3rdparty/libprocess/include/process/collect.hpp <https://reviews.apache.org/r/18311/#comment65783> In your implementation of _await(), you CHECK !isPending and !isDiscarded, but here you're binding to _await onAny result of the future. Why? 3rdparty/libprocess/src/tests/process_tests.cpp <https://reviews.apache.org/r/18311/#comment65784> You should probably test the promise/future.discard behavior too. - Adam B On Feb. 24, 2014, 11:42 a.m., TILL TOENSHOFF wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18311/ > ----------------------------------------------------------- > > (Updated Feb. 24, 2014, 11:42 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. > > There also is a new override that allows await on a single Future, a > convenience approach for allowing a Process based await on a single Future > without forcing the user to render a list or tuple out of that. > > A C++11 and a boost-based implementation have been added. > > This patch also includes tests on those new overrides. > > > Diffs > ----- > > 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 > >
