x.a().then( t1p=>
y.b().then( t2p=>
let t3p = { then(cb) { t1p.then( t1=> t2p.then( t2=>
t1.c(t2).then( t3=> cb(t3) ) ) ) };
...' ) )
(where ...' is ..., transformed to work with a promise t3p instead of t3)
Now, waiting for the .a and .b roundtrips would be delayed until
some code in ...' actually needs to look at t3. One could further
delay looking at t2 if t1.c() could deal with a promise t2p.
[colon removed from above quote per Tab's suggestion]
oops, force of habit, as Tab guessed correctly.
Ok, you've delayed sending the .c until you needed t3p. But that's the
opposite of the promise pipelining optimization! The point is not to delay
sending .c till even later. The point is to send it before the round trips
from .a or .b complete. This code still cannot do that.
I do not expect to be able to emulate pipelining fully in user-land
(at least not in JavaScript).
My aims were to demonstrate that .then does not need to stand in
the way of such an optimization, and that the additional flexibility/
expressiveness provided by non-flattening .then is relevant here.
Back to your objection: there is nowhere to send the .c until you
have t1 at hand. You could, however, move waiting on the t2
dependency to later, by passing the t2 receiver promise t2p to .c
x.a().then( t1p=>
y.b().then( t2p=>
let t3p = { then(cb) { t1p.then( t1=>
t1.c'(t2p).then( t3=> cb(t3) ) ) };
...' ) )
(where t1.c' is t1.c, modified to work with a promise)
Now, the call to t1.c' can go out after the .a roundtrip yet before
the .b roundtrip completes. If you have also moved the callback
code to the remote site, then the call to t1.c' could happen even
without the .a roundtrip completing (from the perspective of
the local site that triggered the chain) because t1 would be on
the same site as the callback code and the remaining data.
This latter aspect of pipelining is simpler to do in the language
implementation (unless the language itself supports sending of
instantiated code, aka closures) - my point was merely to question
the statement that .then would be in the way of such optimization.
Claus
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
