> On Nov. 8, 2013, 12:39 a.m., Benjamin Hindman wrote:
> > 3rdparty/libprocess/include/process/dispatch.hpp, lines 92-93
> > <https://reviews.apache.org/r/15319/diff/1/?file=380494#file380494line92>
> >
> > Why can't we capture this in Promise::associate instead? I think we
> > want these semantics even for code as simple as this:
> >
> > Future<T> future;
> > Promise<T> promise;
> > promise.associate(future);
> > promise.future().discard();
> > CHECK(future.isDiscarded());
> >
> >
> > What about changing Promise::associate thusly:
> >
> > template <typename T>
> > bool Promise<T>::associate(const Future<T>& future)
> > {
> > if (!f.isPending()) {
> > return false;
> > }
> >
> > future
> > .onReady(std::tr1::bind(&Future<T>::set, f,
> > std::tr1::placeholders::_1))
> > .onFailed(std::tr1::bind(&Future<T>::fail, f,
> > std::tr1::placeholders::_1))
> > .onDiscarded(std::tr1::bind(&Future<T>::discard, f));
> >
> > f.onDiscarded(std::tr1::bind(&Future<T>::discard, future)); // You
> > might need a copy of future to get this to compile since discard is not a
> > const function.
> >
> > return true;
> > }
> >
> > Also, maybe we should add a TODO that makes it such that you can't both
> > associate a promise and set a promise ... but we can do that in a later
> > commit.
Ben, I thought about this today. I need to clarify the semantics here:
Case 1:
Future<T> future;
Promise<T> promise;
promise.future().discard();
promise.associate(future);
Case 2:
Future<T> future;
Promise<T> promise;
promise.associate(future);
promise.future().discard();
In case2, obviously, 'future' should be discarded. However, in case1, do you
think 'future' should be discarded or not? One may argue that since
'promise.future()' is discarded before the association, we should not discard
'future' (just like you did in your code). However, if we don't, we may run
into issues in chaining dispatch future discarding.
For example:
class Foo : public Process<Foo> {
Future<bool> func() { return future; }
Future<bool> future;
};
Future<bool> future = dispatch(pid, &Foo::func);
future.discard();
We would expect at this moment, the 'future' field in class Foo should have
been discarded. However, it's likely that the association has not happened yet
(i.e., pdispatcher has not been called yet), thus 'future' field in class Foo
may not be discarded if I follow the semantics in your code.
Any thoughts on this?
Also, can you elaborate why 'you can't both associate a promise and set a
promise'? Thanks!
- Jie
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/15319/#review28471
-----------------------------------------------------------
On Nov. 7, 2013, 7:41 p.m., Jie Yu wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15319/
> -----------------------------------------------------------
>
> (Updated Nov. 7, 2013, 7:41 p.m.)
>
>
> Review request for mesos, Benjamin Hindman, Ben Mahler, and Vinod Kone.
>
>
> Repository: mesos-git
>
>
> Description
> -------
>
> Say you have a process defined as follows:
>
> class FooProcess : public Process<FooProcess>
> {
> public:
> Future<bool> func() { return future; }
> private:
> Future<bool> future;
> };
>
> Then you call dispatch that returns a future:
>
> Future<bool> f = dispatch(process, &FooProcess::func);
>
> If the user discards the future 'f', we expect the 'future' field in
> FooProcess also being discarded. However, this is not the case currently.
>
> This patch fixed this issue.
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/process/dispatch.hpp b337a87
> 3rdparty/libprocess/src/tests/process_tests.cpp 7848599
>
> Diff: https://reviews.apache.org/r/15319/diff/
>
>
> Testing
> -------
>
> make check
>
> Also:
> 3rdparty/libprocess/tests --gtest_repeat=1000
>
>
> Thanks,
>
> Jie Yu
>
>
