What is the intention behind clause 2.2.4 of Promise/A+ spec? about promises-spec HOT 5 OPEN

@FGasper one reason to require async invocation of handlers is that it (perhaps counter-intuitively) makes your code more deterministic.

somePromise.then(handlerA)
doThingB()

If handlers are sometimes called sync and sometimes async, you cannot make any statements about ordering between handlerA and doThingB above. If handlers are always called async, then you know B will happen before A.

This may seem like a subtle issue, but it prevents users from baking in accidental race conditions where they mistakenly think A will always happen before B, because it happened one time that they tested it.

There may be other, better reasons for this requirement. This is just one I happen to think applies.

from promises-spec.

The blocking behavior you describe is certainly one advantage. It's also not totally obvious, but this spec also means that promise handlers execute in a "breadth-first" rather than "depth-first" way — for a given promise pA, acting as the head of several independent promise chains (result of calling pA.then multiple times), the first-level handlers will all execute before the second-level handlers (handlers attached to the promises pB, pC etc. returned by each pA.then). In other words, all of pA's handlers execute before any promise handlers further down in each chain. Whether that was part of the intent of the spec writers I cannot say but it does feel like the "correct" behavior to me.

More generally, it seems to me that the note you quote says the intent clearly enough: it increases deterministic behavior of promises. Handlers will always execute asynchronously, which is easier to reason about than if they sometimes execute synchronously and sometimes don't.

from promises-spec.

In other words, all of pA's handlers execute before any promise handlers further down in each chain.

No, it does not mean that. This might be a behaviour implemented by ES6 Promises and other libraries that use a queue-style asynchronous execution, but it's not required by A+. Btw, this breaks apart anyway when you register handlers after resolution.

from promises-spec.

Ah, my bad! I conflated the "handlers must run in order" and "handlers must be called asynchronously" into a single "handlers must run in order in one async step" concept. Of course if each handler is scheduled independently there can be interleaving without breaking P/A+. Thanks!

And I should have made it clear I was talking about existing promise chains pre-resolution. :-P

from promises-spec.

If I may “jiggle” this thread a bit:

What is the benefit of ensuring that handlers be called asynchronously? I’ve got a promise implementation that I’m using to abstract over whether a given library works synchronously or asynchronously. It was pointed out to me that my implementation, by firing handlers synchronously, violates Promise/A+, but other than the mere fact of that violation, what problems might I find with the approach I’m taking?

from promises-spec.