.JS File Format – Async

Promises

A promise (ES2015) stands for a result that may not be ready yet.

const p = new Promise((resolve, reject) => {
  setTimeout(() => resolve(42), 100);
});

p.then(v => v + 1)            // a new promise for 43
 .then(v => { throw new Error('bad'); })
 .catch(e => 0)               // recovers, giving 0
 .finally(() => stop());      // runs either way; the value passes through

• The executor runs synchronously, and a throw in it rejects the promise.
• Only the first of resolve and reject counts.
• Resolving with a promise, or any thenable (an object with a then method), makes the outer promise adopt its outcome.
• then callbacks always run later as jobs, even when the promise is already settled.
• then and catch return a new promise. What the callback returns or throws decides its outcome.

Async functions and await

AsyncFunctionDeclaration:
    async [no LineTerminator here] function BindingIdentifier ( FormalParameters ) { AsyncFunctionBody }
AsyncArrowFunction:
    async [no LineTerminator here] AsyncArrowBindingIdentifier [no LineTerminator here] => AsyncConciseBody
AsyncMethod:
    async [no LineTerminator here] ClassElementName ( UniqueFormalParameters ) { AsyncFunctionBody }
AwaitExpression:
    await UnaryExpression

async function load(url) {
  try {
    const res = await fetch(url);
    if (!res.ok) throw new Error(res.status);
    return await res.json();
  } catch (e) {
    return null;
  }
}

• An async function (ES2017) always returns a promise. A returned value fulfils it, and a throw rejects it.
• Its body runs synchronously until the first await.
• await x pauses the function and resumes it as a job when x settles, giving the value or throwing the reason. A non-promise value resumes on the next job.
• await is allowed in async functions, async generators, and the top level of modules. Elsewhere it is an identifier in scripts, or an error in modules.
• await is not allowed in parameter defaults of an async function.
• Run tasks in parallel with Promise.all, because sequential awaits wait in turn.

Jobs and the event loop

ECMA-262 defines jobs, units of work a host runs when nothing else is running. Promises schedule theirs through HostEnqueuePromiseJob, with the guarantee that they run in FIFO order, and only when no other job is on the stack. Timers, I/O, rendering and the event loop are defined by the host: the HTML standard for browsers, and libuv and Node.js for Node.js.

In browsers these reaction jobs are called microtasks. After each task, and whenever the stack empties, the microtask queue is drained completely before anything else runs. queueMicrotask adds to the same queue.

console.log('a');
setTimeout(() => console.log('d'));
Promise.resolve().then(() => console.log('c'));
console.log('b');
// prints a, b, c, d

async function f() {
  console.log(1);
  await null;
  console.log(3);
}
f();
console.log(2);
// prints 1, 2, 3

• A long run of microtasks can starve rendering and timers, since the queue is drained first.
• Each worker is a separate agent with its own event loop and memory. They communicate by messages or, with SharedArrayBuffer and Atomics, through shared memory.

Unhandled rejections

A rejected promise with no handler is reported through HostPromiseRejectionTracker. Browsers fire an unhandledrejection event. Node.js by default raises it as an uncaught exception and exits.

Shared memory and Atomics

SharedArrayBuffer and Atomics (ES2017) let agents share bytes and synchronise. Atomics offers atomic reads, writes and compare-and-swap, with wait, notify and waitAsync (ES2024) for waiting. The rules for data races are the Memory Model clause of ECMA-262. Browsers expose SharedArrayBuffer only to cross-origin isolated pages.