Proposal: `await.all {...}` for parallelism

Naveen Chawla naveen.chwl at gmail.com
Tue Nov 26 11:38:46 UTC 2019


Hi Manuel, I think your idea is too much magic, in the sense of not being
straightforward to understand. It actually executes subsequent code first,
e.g.

async {
   x1 = await || doStuffAsync1();
   x2 = await doStuffAsync2();
   x3 = await || doStuffAsync3();
}

In your idea, `doStuffAsync3()` is executed and completed before
doStuffAsync2() even begins! I think this would add bugs due to the
confusion, more particularly if outside variables were modified and relied
upon.

Why not just maximally preserve current JavaScript for parallel execution,
just by omitting `await` in multiple async calls, simply wrapping it in an
`await.all` block to ensure completion before code continues past the
block. This surely is the more straightforward way to satisfy the same
goals?

On Tue, 26 Nov 2019 at 11:22, manuelbarzi <manuelbarzi at gmail.com> wrote:

> hi Tom
>
> So the parallel awaits would execute before the series awaits?
>>
>
> not exactly. it would group the parallel awaits at the position the first
> parallel await|| is sentenced.
>
> following the demo i sent:
>
>
> // NOTE async {} = asynchronous scope (it groups parallel awaits => `await||`)
> // NOTE p? = function call that returns a promise (? = just and index)
>
> async {
>     const x1 = await || p1()
>     const x2 = await p2(x1)
>     const x3 = await || p3()
>     const x10 = await p10(x2, x3)
>
>     let x4, x5, x6
>
>     async {
>         x4 = await || p4(x1, x2)
>         x5 = await || p5(x2, x3)
>         x6 = await p6(x4, x5, x10)
>     }
>
>     let x7, x8, x9
>
>     async {
>         x7 = await || p7(x4, x6)
>         x8 = await p8(x6, x7)
>         x9 = await || p9(x5, x6)
>     }
>
>     await p11(x8, x9)
> }
>
> in the outer block, the first sentence is already parallel, ok, then all
> parallel awaits in this block will group at first position, siblings of
> this first one (that is p1 and p3).
>
> in the inner blocks too (just a casualty i created the demos this way, but
> could be different and still work). in the first inner block, p4 and p5,
> and in the second inner block, p7 and p9.
>
> "transpiling" it to promises, it would resolve a complex scenario like
> following (the demo could be improved, of course):
>
>
> // it would resolve a tree of parallel and series like following with traditional promises
>
> Promise.all([p1(), p3()])
>     .then((x1, x3) =>
>         p2(x1)
>             .then(x2 =>
>                 p10(x2, x3)
>                     .then(x10 => {
>                         let x4, x5, x6
>
>                         return Promise.all([p4(x1, x2), p5(x2, x3)])
>                             .then(results => [x4, x5] = results)
>                             .then(() => p6(x4, x5, x10))
>                             .then(_x6 => x6 = _x6)
>                             .then(() => {
>                                 let x7, x8, x9
>
>                                 return Promise.all([p7(x4, x6), p9(x5, x6
> )])
>                                     .then(results => [x7, x9] = results)
>                                     .then(() => p8(x6, x7))
>                                     .then(_x8 => x8 = _x8)
>                                     .then(() => p11(x8, x9))
>                             })
>                     })
>             )
>     )
>
> What if there are series awaits before the first parallel await?
>>
>
> no problem, if there was one before, then in it would be chained first in
> the outer promise, and following it would be the promise.all for the next
> parallel group.
>
>
>> What if the parallel awaits depend on the results of those series awaits?
>> It reads very strangely.
>>
>
> that's totally valid as far as the parallel await is located after the
> series awaits.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20191126/ed6d8a91/attachment.html>


More information about the es-discuss mailing list