V8 adds support for top-level await

Post by sieabahlpark » Wed, Sep 25, 2019, 4:33 AM UTC

Scooty wrote: post #83

megous wrote: post #9

Earlier quoted context omitted.

It's nice, I guess, but huge? Instead of: async function main() { // code } main().catch(console.error); I'll be maybe writing: try { // code } catch (ex) { console.error(ex); } Hrm?

Top level await does more than remove a main function. If you import modules that use top level await, they will be resolved before the imports finish. To me this is most important in node where it's not uncommon to do async operations during initialization. Currently you either have to export a promise or an async function.

Post by esprehn » Wed, Sep 25, 2019, 4:45 AM UTC

nine_k wrote: post #163

cellularmitosis wrote: post #142

Earlier quoted context omitted.

> Even at CPU level, "sequential" instructions aren't Within the context of the argument you are making, this is disingenuous. There's a big pile of transistors which determine whether it is safe to reorder those instructions.

Thar same pile of transistors, with a thick layer of software, determines whether it's safe to proceed a coroutine. const foo = async () { const ice = await freeze(water); const wCream = await whip(cream); const base = await pour(liquor, ice); const cocktail = await put(base, wCream); return cocktail.serve(); } In the above fragment, `freeze` and `whip` may run in any order or in parallel, you don't get to choose. St…

    const foo = async () =>
      freeze(water)
        .then(ice => whip(cream)
          .then(wCream => pour(liquor, ice)
            .then(base => put(base, cream)
              .then(cocktail => cocktail.serve()))));

Post by _bxg1 » Wed, Sep 25, 2019, 4:49 AM UTC

ihuman wrote: post #81

_bxg1 wrote: post #48

Earlier quoted context omitted.

Data races are impossible in JavaScript because it's single-threaded. Race conditions are possible in any language that can do anything asynchronous, which is basically all of them. But the general benefit you get from JS being single-threaded is the fact that any given callback is transactional. No other code will ever come in and mutate state between two regular lines of JavaScript code. Achieving this is pretty mu…

> when you use async/await instead of promises or callbacks, things do change because two sequential lines of code are no longer two truly sequential instructions I thought async/await was just syntactic sugar for promises?

Post by tlrobinson » Wed, Sep 25, 2019, 4:51 AM UTC

ghusbands wrote: post #120

millstone wrote: post #106

Earlier quoted context omitted.

Here's an example of how you might get a race condition in JS: async function deduct(amt) { var balance = await getBalance(); if (balance >= amt) return await setBalance(balance - amt); } One way to resolve this would be with a mutex to protect the balance during the critical section (which is async). What would you suggest instead?

More subtly, here's an example of a hidden race condition in JS: async function totalSize(fol) { const files = await fol.getFiles(); let totalSize = 0; await Promise.all(files.map(async file => { totalSize += await file.getSize(); })); // totalSize is now way too small return totalSize; }

  async function totalSize(fol) {
    const files = await fol.getFiles();
    const sizes = await Promise.all(files.map(file => file.getSize()));
    return sizes.reduce((acc, size) => acc + size);
  }

Post by ithkuil » Wed, Sep 25, 2019, 4:53 AM UTC

DrJokepu wrote: post #109

millstone wrote: post #106

Earlier quoted context omitted.

Here's an example of how you might get a race condition in JS: async function deduct(amt) { var balance = await getBalance(); if (balance >= amt) return await setBalance(balance - amt); } One way to resolve this would be with a mutex to protect the balance during the critical section (which is async). What would you suggest instead?

I mean, if something like this is behind a promise or an async call, that probably means that there's I/O involved (no point using async to access local in-memory data), which means that the local locking primitive won't be incredibly useful, you're going to have to lock it via whatever mechanism the I/O channel (or some API using the I/O channel) provides, such as file locking or some API call or something.