I fill a tech-debt ticket to record this in
https://issues.apache.org/jira/browse/MESOS-5079
On Wed, Mar 30, 2016 at 5:25 PM, Joris Van Remoortere <jo...@mesosphere.io>
wrote:
> I think the API of future intuitively suggests parts of the chain will
> execute in a specific order. The type system even enforces some of these
> IIUC.
>
> For example:
> func().then([](T) -> X {...}).repair([](Future<X>) -> X {...}).then([](X)
> -> Y {...}).onAny([](Future<Y>){...})
>
> As you can see, the .onAny(Future<Y>) can't just start executing on
> the T returned
> by func().
>
> I think it would be confusing and error prone to remember that sibling `.
> onAny` pairs could execute in arbitrary order, but members along the chain
> such as `.then` and `.repair` could not.
>
> I'm not sure the benefits of executing multiple `.onAny` calls in parallel
> in the future (if we ever need to) outweigh the inconsistency in the API
> regarding ordered execution of certain chains (At least as the API is
> currently designed).
>
> —
> *Joris Van Remoortere*
> Mesosphere
>
> On Wed, Mar 30, 2016 at 12:25 AM, Benjamin Mahler <bmah...@apache.org>
> wrote:
>
> > I don't believe we have made this assumption often, and I'm not convinced
> > it's a problem in Future.
> >
> > Why would one make such an assumption in the first place? It seems
> brittle,
> > especially when callbacks are executed in deferred contexts that Future
> is
> > unaware of. It also limits our flexibility within Future if we add these
> > ordering semantics.
> >
> > On Tue, Mar 29, 2016 at 2:41 AM, Joris Van Remoortere <
> jo...@mesosphere.io
> > >
> > wrote:
> >
> > > Rather than saying we shouldn't make this assumption (which I assume
> has
> > > already been made in places, and will likely be made again), can we fix
> > the
> > > problem?
> > > There's a `TODO` already suggesting running the callback in a separate
> > > execution environment.
> > > We could also synchronize with thread setting the future to true.
> > >
> > > I'd rather discuss and fix the problem, than try to enforce avoiding
> this
> > > case.
> > >
> > > Thoughts?
> > >
> > > —
> > > *Joris Van Remoortere*
> > > Mesosphere
> > >
> > > On Tue, Mar 29, 2016 at 2:50 AM, Jie Yu <yujie....@gmail.com> wrote:
> > >
> > > > Hi,
> > > >
> > > > While digging a bug reported in, I realized an assumption we
> shouldn't
> > > make
> > > > in our code.
> > > > https://issues.apache.org/jira/browse/MESOS-5023
> > > >
> > > > Say you have the following code:
> > > >
> > > > void some_func()
> > > > {
> > > > future
> > > > .onAny(callback_A)
> > > > .onAny(callback_B);
> > > > }
> > > >
> > > > Question: will callback_A already be executed before callback_B?
> > > >
> > > > The answer is NO. We should never assume that. Under the following
> > > > interleaving, callback_B can be invoked first:
> > > >
> > > > Thread-1 Thread-2
> > > >
> > > > onAny(callback_A) {
> > > > onAnyCallbacks.push_back(callback_A);
> > > > }
> > > > set() {
> > > > lock()
> > > > if (state ==
> > > > PENDING) {
> > > > state =
> > READY;
> > > > result =
> > true;
> > > > }
> > > > unlock();
> > > >
> > > > onAny(callback_B) {
> > > > lock()
> > > > if (state != PENDING) {
> > > > run = true
> > > > }
> > > > unlock()
> > > >
> > > > if (run) {
> > > > callback_B()
> > > > }
> > > >
> > > > if (result)
> {
> > > >
> > > > internal::run(data->onAnyCallbacks,
> > > > *this);
> > > > }
> > > >
> > > > - Jie
> > > >
> > >
> >
>
--
Best Regards,
Haosdent Huang
