Where'd Promise#done go?

Mark S. Miller erights at google.com
Fri Jun 21 06:49:17 PDT 2013


On Fri, Jun 21, 2013 at 1:30 AM, Claus Reinke <claus.reinke at talk21.com>wrote:

>    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).
>

<
https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/makeQ.js>
supports promise pipelining in user land, using the makeRemote and makeFar
extension points.



>
> 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.


If we distinguish .then vs .there, you are describing .there above. With
this distinction, do you agree that .then prevents this optimization?



>
>
> Claus
>
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130621/44caadef/attachment.html>


More information about the es-discuss mailing list