Promise/Future: asynchrony in 'then'
slightlyoff at google.com
Wed May 1 09:07:44 PDT 2013
On Wednesday, May 1, 2013, Tab Atkins Jr. wrote:
> > The promises-aplus spec has a note that confuses me
> > https://github.com/promises-aplus/promises-spec#notes
> > 1. In practical terms, an implementation must use a mechanism such
> > setTimeout, setImmediate, or process.nextTick to ensure that
> > and onRejected are not invoked in the same turn of the event loop as
> > call to then to which they are passed.
> > I have not yet been able to decide whether DOMFuture has a
> > similar provision, or how this note is meant to be interpreted.
> Juan already pointed out the "queue a task" language, so this is answered.
This is far too glib. The spec may very well be wrong on this point. The
design goal isn't to require a full yeild of the event loop, but instead to
force async code flow -- that means that resolving and calling back should
be able to happen at "end of microtask"; the same timing as
> > The aspect that worries me is that this note is attached not to the
> > creation of promises but to the definition of 'then'. Is that because
> > of the implicit return lifting (if 'then' callbacks do not return
> > wrap the return in a new promise), or is there something else going on?
> Yes. The promise itself may be fulfilled synchronously - the resolver
> callback is called immediately, and can immediately call
> "r.accept(val)" if it wants. The important part is that chained
> callbacks (through .then(), .done(), etc.) be handled async.
> > As long as the 'then' callbacks return Promises, the idea of resolved
> > Promise creation as left and right identity of 'then'
> > Promise.of(value).then(cb) = cb(value)
> > promise.then(Promise.of) = promise
> > would seem to require no additional delays introduced by 'then' (promise
> > creation decides semantics/delays, 'then' only passes on intermediate
> > results).
> > Could someone please clear up this aspect? How is that note meant
> > to be interpreted, and do other Promise/Future specs have similar
> > provisions?
> > Claus
> > PS. Prompted by this blog post:
> The reason you want to maintain asynchrony, even when it's possible to
> go ahead and run callbacks async, is so that the operation of futures
> is *predictable*. It doesn't matter (and it's unobservable) whether a
> future is pending or fulfilled - you just attach a callback to it, and
> it'll run no earlier than the next event-loop tick, so the rest of the
> code in your function can depend on the fact that it hasn't run yet.
> If it sometimes runs synchronously, then you can't depend on that -
> the rest of the code in your function may be assuming that certain
> outside variables don't change, but the promise might tweak them
> synchronously, or might leave them alone until it runs async.
> es-discuss mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss