Движок против цикла

У движка нет цикла событий

Обзорные браузерные уроки трактуют цикл событий как единую машину — browser/01-event-loop/01-loop-model — это взгляд со стороны рантайма. Этот юнит — взгляд со стороны движка, и первая поправка структурная: у движка нет цикла событий. ECMAScript, язык, который реализует V8, вообще его не упоминает. Спецификация определяет jobs и job queue и говорит, что хост обязан рано или поздно запустить очередь jobs — но алгоритм, решающий, когда и какую задачу запускать следующей, явно отдан хосту (через HOST-хуки HostEnqueuePromiseJob, HostCallJobCallback).

Итак, разделение труда такое:

• Хост (message loop Chromium, Node плюс libuv, Deno, Bun) владеет циклом. Он держит очереди макрозадач (таймеры, завершения I/O, message-события), решает, какая задача пойдёт следующей, и управляет рендерингом. Это while (true) на самом верху.
• Движок (V8) владеет одной очередью — очередью микрозадач (тем самым «jobs queue» из ECMAScript) — и выставляет одну операцию для её осушения: PerformMicrotaskCheckpoint. Он исполняет JavaScript, который ему передал хост, до конца, и на выходе осушает свои микрозадачи.

Хост и движок сцеплены настолько точно, что порядок асинхронности перестаёт ощущаться как фольклор — поймите это разделение один раз, и каждый следующий async-сюрприз получает механическое объяснение.

Когда говорят «цикл событий», имеют в виду цикл хоста. Когда говорят «микрозадачи запускаются после текущей задачи», имеют в виду чекпоинт движка. Смешение этих двух — причина, по которой порядок асинхронности ощущается как фольклор, а не как механизм.

Форма одного оборота: хост вызывает, движок возвращает, микрозадачи осушаются

Один оборот цикла хоста — это вызов внутрь движка и возврат наружу. Хост выбирает одну макрозадачу (скажем, сработавшее событие click или истёкший таймер) и вызывает движок на связанном с ней JavaScript-колбэке. Движок кладёт фрейм на стек, исполняет ваш код до конца — JavaScript исполняется run-to-completion, никакого вытеснения посреди функции нет — и когда стек вызовов пустеет, движок выполняет чекпоинт микрозадач: он осушает каждую поставленную в очередь микрозадачу (реакции Promise, jobs от queueMicrotask), пока очередь не опустеет, включая микрозадачи, поставленные другими микрозадачами. Только тогда управление возвращается хосту, который рендерит (в браузере) и выбирает следующую макрозадачу.

Ключевая деталь: осушение микрозадач происходит внутри единственного вызова хост-в-движок, до того как движок вернётся. С точки зрения хоста, запуск обработчика клика и запуск каждой реакции Promise, которую он запланировал, — это одна неделимая задача. Вот почему микрозадачи всегда идут перед следующим таймером, перед следующим рендером, перед чем угодно следующим: они не отдельная задача, которую планирует хост, — они хвост уже исполняющейся задачи.

Кто даёт чекпоинт и кто его вызывает

PerformMicrotaskCheckpoint — это V8; а вот решение его вызвать частично разделено. V8 автоматически запустит микрозадачи, когда стек вызовов JS опустеет (политика микрозадач «auto» по умолчанию, используемая браузером). Node использует явную политику: libuv прогоняет фазу, а Node сам вызывает runMicrotasks() в чётко определённых точках (после каждого колбэка макрозадачи и между фазами) — поэтому у Node свои правила порядка, которые мы разберём в следующем уроке. В любом случае очередь и осушение — движка; ритм — хоста.

Run-to-completion — несущее правило

Всё вышесказанное опирается на одну гарантию движка: run-to-completion (выполнение до завершения). Как только хост передал движку колбэк, этот колбэк исполняется от начала до конца без вкрапления другого JavaScript. Никакая вторая задача, никакая микрозадача — ничто его не вытесняет. Именно это делает цикл for атомарным с точки зрения программы и именно это заставляет await (следующие уроки) нуждаться в явном механизме приостановки — движок не может просто «поставить функцию на паузу» так, как ОС ставит на паузу поток, потому что run-to-completion это запрещает. Функция должна вернуться хосту, а микрозадача — возобновить её позже.