Where'd Promise#done go?
claus.reinke at talk21.com
Thu Jun 20 10:34:00 PDT 2013
> 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
><http://erights.org/talks/thesis/markm-thesis.pdf>. 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
... ) ) )
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,
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), 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...
What am I missing here?
More information about the es-discuss