>can we fix the problem? +1 And I think need make sure all other callbacks ordering guarantee as well. How about fill a ticket for this? One approach I could think is we always put the callback to callbacks vector and trigger it run if status != PENDING.
On Tue, Mar 29, 2016 at 5:41 PM, 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
