Where'd Promise#done go?
Mark S. Miller
erights at google.com
Thu Jun 20 11:15:54 PDT 2013
On Thu, Jun 20, 2013 at 10:34 AM, Claus Reinke <claus.reinke at talk21.com>wrote:
> I'm worried that you may be suffering from and spreading a terminology
>> confusion. "Promise pipelining" is an important latency reduction
>> optimization when using promises over a network. See Chapter 16 of
>> Using .then, either
>> with or without the return result, **prevents** promise pipelining, which
>> is another reason to emphasize asynchronous message sending and
>> deemphasize .then.
> I couldn't imagine why you would think that using .then would prevent
> promise pipelining. A properly designed, monadic .then, is nothing but
> a more powerful let. Perhaps you could elaborate?
> Naively translating the standard pipeline example gives
> x.a().then( t1=>
> y.b().then( t2=>
> t1.c(t2).then( t3=>
> ... ) ) )
> where x, y, t1, and t2 are meant to live on the same remote machine,
> computation is meant to proceed without delay into the ... part, and
> the implementation is meant to take care of avoiding unnecessary
> round-trips for the intermediate results.
> This is naïve because the synchronous method calls should really
> be asynchronous message sends. If we assume local proxies that
> forward local method calls to remote objects and remote results
> to local callbacks, then y.b() will not start until t1 comes back.
> But if t1 is itself a promise, then it can come back immediately,
I think this is what you are missing. If x.a() returns, for example, an
int, then x!a() returns a promise that will turn out to be a
promise-for-int. In that case, x!a().then(t1 => ...t1...), the callback
will only be invoked with t1 bound to the int itself. This can't happen
prior to the completion of the round trip.
> and the same applies to t2 and t3. So computation can proceed
> directly to the ... part, with delays happening only when required
> by data dependencies.
> A user-level promise will not have the same opportunities for
> network traffic optimization as an implementation-level future
> (an obvious one would be moving the callback code to where
> the data is)
Moving the callback code to where the data is is indeed an important idea.
Back when .then was called "when", this was called "where". With the
renaming of "when" to "then", "where" is renamed "there" <
and .then must be kept distinct because they have very different security
properties, as well as very different failure and progress properties under
> , but the .then itself does not prevent optimizations.
> Unless, that is, one insists on flattening promises (no promises
> passed to .then-callbacks), which would sequentialize the chain...
I don't see how this is relevant, as the round-trip above is still forced
on flatMap. But yes, we do insist on this flattening. That's the difference
between .then and .flatMap.
> What am I missing here?
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss