> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, lines 240-242
> > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line240>
> >
> > Can the compiler automagically convert a Future<T> to a
> > Future<Future<T> >?
Yes, that is template magic and this constructor template make it possible
within future.hpp:
template <typename T>
Future<T>::Future(const T& _t)
: data(new Data())
{
set(_t);
}
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, lines 247-250
> > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line247>
> >
> > 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> >?
See above.
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, line 332
> > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line332>
> >
> > Can we add something to the comment to clarify that this is actually
> > the 'else' case of (__cplusplus >= 201103L)?
We do not do this in other cases (like deferred.hpp), hence I followed that
pattern.
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, lines 229-235
> > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line229>
> >
> > Why delete the Promise* here? What if the caller were still using it?
> > Can we use shared/owned pointers here to clarify?
I think this could in fact not happen. But on the other hand, clear signals are
great, hence I changed to Owned variant.
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/collect.hpp, lines 46-51
> > <https://reviews.apache.org/r/18311/diff/1/?file=498993#file498993line46>
> >
> > Why this new API? You've justified the tuple version, but not the
> > single-future version. Or is this for composability?
It is mostly convenience. Not justifying it in be description was an omission I
shall correct.
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/c++11/collect.hpp, lines 46-48
> > <https://reviews.apache.org/r/18311/diff/1/?file=498992#file498992line46>
> >
> > Do we need this when we have the other calls?
> > s/future1/future/
See below.
> On Feb. 20, 2014, 8:16 p.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/c++11/collect.hpp, lines 205-207
> > <https://reviews.apache.org/r/18311/diff/1/?file=498992#file498992line205>
> >
> > So, await waits for all futures to be ready/failed/discarded, but
> > collect waits for them all to be ready?
That is it, yes.
- TILL
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18311/#review35015
-----------------------------------------------------------
On Feb. 20, 2014, 3:59 p.m., TILL TOENSHOFF wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18311/
> -----------------------------------------------------------
>
> (Updated Feb. 20, 2014, 3:59 p.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
>
>
