async/await, десахаризированный

async/await — это генератор плюс драйвер

async/await — это чистый синтаксический сахар; движок десахаризирует его в корутину. async-функция механически — это генератор, чьи точки yield — это await’ы, в паре с автоматическим драйвером, который продвигает генератор каждый раз, когда await’ируемое значение урегулируется. Два факта выпадают сразу:

1. async-функция всегда возвращает Promise. Её вызов выполняет тело синхронно до первого await, затем возвращает pending-Promise, представляющий «итоговое завершение этой функции». return x внутри — fulfils этот Promise значением x; брошенная ошибка — rejects его.
2. await x — это точка приостановки. Когда управление доходит до await x, движок: оборачивает x через PromiseResolve (превращая любое значение или thenable в Promise, на который подписаться), регистрирует продолжение как реакцию на этом Promise и возвращается из функции — отдавая поток назад хосту. Когда await’ируемый Promise урегулируется, зарегистрированная реакция (микрозадача) возобновляет функцию сразу после await, подставив значение (или перебросив отклонение).

Поскольку возобновление — это микрозадача, async-функция с двумя await’ами — не одна синхронная единица: она нарезана на куски, которые чередуются с каждой другой ожидающей микрозадачей между возобновлениями. Это линза урока: await — это yield драйверу, а драйвер работает на очереди микрозадач.

История: await раньше стоил три тика

Исходная спецификация ES2017 для await была расточительной. Чтобы обработать случай, когда вы await’ите thenable, спецификация говорила: возьми операнд, создай совершенно новый одноразовый Promise, урегулируй его операндом, затем .then на нём, чтобы подписаться. Даже когда операнд уже был нативным Promise, вы платили за одноразовый Promise и его job принятия thenable. Стоимость, измеренная в тиках микрозадач до возобновления функции, была около трёх тиков для await p, где p — нативный Promise, против одного тика для эквивалентного p.then(...). В горячем цикле, полном await’ов, это утраивало трафик микрозадач.

// До V8 7.2, `await p` был примерно эквивалентен:
const throwaway = new Promise(resolve => resolve(p)); // принять p — лишние тики
throwaway.then(resume);                                // подписаться — ещё тик
// ≈ 3 тика микрозадач до возобновления, даже для нативного Promise p

V8 7.2 (2018): await ≈ p.then

V8 7.2 выпустил оптимизацию await. Когда await’ируемый операнд — нативный Promise (настоящий Promise, а не чужой thenable), движок полностью пропускает танец с одноразовым Promise и регистрирует реакцию-возобновление прямо на операнде — ровно как сделал бы p.then(resume). Это схлопывает await p с ~3 тиков до 1 тика, совпадая с написанным вручную .then. Затем TC39 изменил саму спецификацию под это (флаг --harmony-await-optimization гейтил это во время раскатки; теперь это поведение по умолчанию и спецификации). Практический итог для сеньоров: начиная с движков конца 2018 года, вы больше не платите налог в тик за использование await вместо .then на нативных Promise — пишите то, что читается яснее. Налог возвращается, только если вы await’ите не-нативный thenable, которому всё ещё нужен job принятия.

Zero-cost async stack traces

Та же эпоха релизов принесла zero-cost async stack traces (трассировки стека без накладных расходов во время выполнения). Проблема: когда ошибка всплывает на три await’а вглубь, синхронный стек вызовов давно исчез — каждый await вернулся хосту, поэтому наивная трасса показывает лишь самое внутреннее возобновление без цепочки вызывающих. Старый фикс (оставлен под флагом) записывал стек при каждом создании Promise, что было дорого на горячих путях. Подход zero-cost вместо этого восстанавливает async-фреймы по требованию из цепочки Promise: V8 обходит ссылки [[PromiseFulfillReactions]] (из урока 3) назад, чтобы перестроить логический async-стек вызовов только когда DevTools реально его запрашивает (когда вы попадаете на точку останова или читаете error.stack в контексте отладки). Быстрый путь не платит ничего — никакой аллокации на await — и всё же вы получаете полную async-трассу в отладчике. «Zero-cost» означает нулевую стоимость, когда вы не отлаживаете.

Распространение ошибок: отклонение становится throw

Когда вы оборачиваете await в try/catch и он действительно ловит сетевую ошибку, возникает вопрос: как асинхронное отклонение попадает в синхронный catch-блок? Поскольку реакция-возобновление регистрируется и для fulfilment, и для rejection, await превращает асинхронное отклонение обратно в синхронно выглядящий throw внутри функции. Когда await’ируемый Promise отклоняется, движок возобновляет функцию, бросая причину отклонения в выражении await — поэтому try/catch вокруг await ловит её ровно так, как если бы синхронная функция бросила. В этом весь эргономический выигрыш async/await: линейная обработка ошибок поверх по своей природе нелинейного потока управления. Обратная сторона — ловушка из урока 3: не-await’нутый, не пойманный отклонённый Promise порождает unhandledrejection, потому что не была зарегистрирована реакция, чтобы превратить его в ловимый throw.