[jira] [Commented] (MESOS-5079) Ordering guarantee of future.onAny callbacks

["haosdent (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15222059#comment-15222059 ] 

haosdent commented on MESOS-5079:
---------------------------------

Pick up some comments from the thread, could found more context in above link.
{code}
>From [~bmahler]:
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.
{code}

{code}
>From [~jvanremoortere]:
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).
{code}

> Ordering guarantee of future.onAny callbacks
> --------------------------------------------
>
>                 Key: MESOS-5079
>                 URL: https://issues.apache.org/jira/browse/MESOS-5079
>             Project: Mesos
>          Issue Type: Bug
>            Reporter: haosdent
>              Labels: libprocess, tech-debt
>
> Just copy the discussion from dev mailing list [Ordering guarantee of future.onAny callbacks | http://search-hadoop.com/m/0Vlr6hEZyWYHiwg2]
> {noformat}
> ...
> 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
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)