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 > > >
