Где модель врёт: планировщик на промисах и замкнутость мира

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

Соберём такую версию и посмотрим на неё в деле. Она даже короче: перерыва между колбэками у неё нет вовсе, вместо него await, а сроков она не считает — таймер просто ждёт следующего оборота. Всё остальное на месте: три очереди фаз, снимок очереди на входе в фазу, оборот по кругу и номер оборота в каждой строке вывода.

Важных строк в нём две. Первая — объявление fake.run асинхронной функцией: у цикла появился свой промис, и снаружи его теперь можно дождаться. Вторая — await fn() в каждой из трёх фаз: колбэк вызывается с обещанием дождаться, пока он кончится. Обе выглядят как забота о правильности, и в каждой спрятано по ошибке — но увидеть это проще на выводе, чем на словах.

Прогноз к примеру: колбэк фазы проверки заводит цепочку из двух реакций промиса и модельный таймер. В каком порядке напечатаются четыре строки и на каком обороте окажется каждая? Опереться есть на что: в Node цепочка промиса разбирается целиком раньше любого таймера.

// Тот же планировщик, но перерыва между колбэками нет: фазы разбирает await
const fake = {
  timers: [], // фаза сроков
  poll: [], // фаза опроса
  check: [], // фаза проверки
  turn: 0, // номер оборота
};

fake.timeout = (fn) => fake.timers.push(fn); // сроков эта версия не считает: таймер ждёт следующего оборота
fake.io = (fn) => fake.poll.push(fn);
fake.immediate = (fn) => fake.check.push(fn);

// «пусть цикл будет настоящим асинхронным»: колбэк вызывается через await
fake.run = async () => {
  while (fake.timers.length + fake.poll.length + fake.check.length > 0) {
    fake.turn += 1;
    for (const fn of fake.timers.splice(0)) await fn();
    for (const fn of fake.poll.splice(0)) await fn();
    for (const fn of fake.check.splice(0)) await fn();
  }
};

// колбэк фазы проверки заводит цепочку из двух реакций промиса и модельный таймер
fake.immediate(() => {
  console.log(`оборот ${fake.turn}: колбэк проверки`);
  Promise.resolve()
    .then(() => console.log(`оборот ${fake.turn}: промис, шаг 1`))
    .then(() => console.log(`оборот ${fake.turn}: промис, шаг 2`));
  fake.timeout(() => console.log(`оборот ${fake.turn}: модельный таймер`));
});
fake.run();

Модельный таймер встал между двумя звеньями одной цепочки промиса, а «оборот 2» в последней строке говорит, сколько всего прошло между ними: целый круг цикла с фазой сроков внутри. В настоящем Node такого порядка не бывает ни при каких условиях — цепочка разбирается до дна в перерыве между колбэками, и никакая фаза в неё не влезает. Планировщик, которому мы поверили за то, что он «настоящий асинхронный», соврал в первом же примере.

Пример не подобран нарочно и не сломан: те же четыре строки на честной модели дают другой порядок. Враньё сидит в одной строке самого планировщика, а не в сюжете.

Причина одна, и она в await. Он ставит на паузу функцию, в которой написан, и отдаёт управление наружу; а продолжение после паузы возвращается не само по себе, а микрозадачей — в ту самую очередь, где уже стоят реакции промисов из примера. Значит, после каждого колбэка fake.run встаёт в общую очередь и ждёт там наравне со всеми. Фаза модели перестала быть фазой: теперь это просто очередная микрозадача.

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

Никакой мистики: планировщик не «обгоняет» цепочку и не важнее её. Он просто встал в ту же очередь и получил ход по-честному, в порядке живой очереди. Беда в том, что очередь эта — предмет урока. Модель, которая объясняет очередь промисов, устроена на очереди промисов и в первом же примере показывает её поведение вместо своего.

А теперь самое неприятное свойство такой модели: врёт она не всегда. Уберём из цепочки второе звено — сюжет тот же, работ в очереди стало на одну меньше. Прогноз: изменится ли порядок и совпадёт ли он на этот раз с настоящим Node?

// тот же планировщик и почти тот же сюжет: цепочка теперь из одного звена
fake.immediate(() => {
  console.log(`оборот ${fake.turn}: колбэк проверки`);
  Promise.resolve().then(() => console.log(`оборот ${fake.turn}: промис`));
  fake.timeout(() => console.log(`оборот ${fake.turn}: модельный таймер`));
});
fake.run();

Порядок правильный: реакция промиса, потом таймер — именно так ответил бы и node. Но правильный он по случайности. В очереди оказалось по одной работе с каждой стороны, чередование дало верный ответ, а поменяйся число звеньев — и он снова станет неверным. Модель, которая права через раз, опаснее той, что врёт всегда: проверить её одним примером нельзя, а два примера подряд никто не пробует.

На честной модели ничего подобного не случается, и не потому, что она умнее. Она вся — один синхронный кусок кода: while, вызовы колбэков, осушение очередей. Пока loop.run() не вернулся, ни одна микрозадача среды не выполнится: вклиниться в середину оборота нечему. Тот же сюжет с цепочкой, только обе микрозадачи модельные:

// тот же сюжет на честной модели: цепочка микрозадач и таймер на ноль
loop.immediate(() => {
  console.log(`оборот ${loop.turn}: колбэк проверки`);
  loop.microtask(() => {
    console.log(`оборот ${loop.turn}: микрозадача, шаг 1`);
    loop.microtask(() => console.log(`оборот ${loop.turn}: микрозадача, шаг 2`));
  });
  loop.timeout(() => console.log(`оборот ${loop.turn}: модельный таймер`), 0);
});
loop.run();

Порядок совпал с тем, что даёт Node: оба шага цепочки в первом обороте, таймер — во втором. И совпал он не случайно, а потому, что так написано в call: микрозадача в честной модели — это loop.microtask, то есть запись функции в массив, и второе звено цепочки — тоже запись в массив, сделанная по ходу осушения. Модель изображает механизм, а не пользуется им. Ровно это и позволяет ей не врать: у изображения нет своих сроков и своей очереди, оно делает только то, что написано в тридцати строках рядом.

Признак вранья виден раньше вывода: если в самом планировщике есть await, then, setTimeout или queueMicrotask, его порядок задаёт среда, а не тридцать строк рядом. Читать при этом весь код не нужно — хватит поиска по четырём словам.

Утверждение «фаза не может влезть в середину цепочки» стоит проверить, а не объявить: без эталона спор двух моделей остаётся спором двух мнений. Колбэк таймера заводит цепочку из двух реакций, тик и ещё один таймер на ноль. Прогноз: где окажется второй таймер — между звеньями цепочки, как в нечестной модели, или после неё?

// Эталон честности: что Node делает с цепочкой промиса, тиком и вторым таймером,
// заведёнными внутри колбэка первого таймера. С этим порядком и сверяется модель.

setTimeout(() => {
  console.log('таймер: колбэк начался');

  // цепочка из двух реакций: вторая появится только когда выполнится первая
  Promise.resolve()
    .then(() => console.log('таймер: промис, шаг 1'))
    .then(() => console.log('таймер: промис, шаг 2'));

  process.nextTick(() => console.log('таймер: тик'));
  setTimeout(() => console.log('следующий оборот: второй таймер'), 0);

  console.log('таймер: колбэк кончился');
}, 0);

таймер: колбэк начался
таймер: колбэк кончился
таймер: тик
таймер: промис, шаг 1
таймер: промис, шаг 2
следующий оборот: второй таймер

Порядок такой: тик, оба звена цепочки и только потом второй таймер. Второе звено появилось во время перерыва между колбэками — и разобралось в том же перерыве, потому что перерыв кончается не по числу работ, а по пустоте обеих очередей. Цикл получит ход, когда разбирать станет нечего, и ни мгновением раньше.

Тик в этом выводе идёт первым из отложенного, и стоит он здесь не для полноты картины. Перерыв между колбэками состоит из двух очередей, и обе разбираются до дна прежде, чем цикл сдвинется хоть на шаг: сначала тики, потом реакции промисов вместе со всем, что те по дороге завели. Нечестный планировщик ломает и это: у него между работами перерыва проходят целые фазы — потому что перерыва у него нет вовсе.

Вот с этим выводом и сверяется любая модель цикла событий. Наша ему не противоречит: в ней цепочка тоже разобралась целиком до фазы сроков. Нечестная противоречит прямо: у неё между звеньями прошла целая фаза. Значит, спор кончен — дело не во вкусе и не в стиле, модель разошлась с проверяемым фактом, и любое другое её утверждение о порядке теперь не стоит ничего.

Заметьте, чем именно кончился спор. Не ссылкой на документацию, не авторитетом и не рассуждением — снятым выводом, который можно снять заново на своей машине и получить то же самое. Поэтому в этой части рядом с моделями и стоят записанные прогоны: модель показывает механизм, а прогон отвечает за то, что механизм тот самый.

У синхронности есть цена, и знать её надо заранее. Раз loop.run() — один синхронный кусок, то для среды весь наш цикл целиком — часть одной задачи: микроочередь она разберёт не раньше, чем этот кусок кончится. Проверим, что это значит на практике: положим в колбэк модели настоящий Promise рядом с модельной микрозадачей. Прогноз: какой по счёту напечатается строка про настоящий промис и какой номер оборота в ней окажется?

// в колбэк честной модели попал настоящий промис — не loop.microtask, а Promise
loop.immediate(() => {
  console.log(`оборот ${loop.turn}: колбэк проверки`);
  Promise.resolve().then(() => console.log(`оборот ${loop.turn}: настоящий промис`));
  loop.microtask(() => console.log(`оборот ${loop.turn}: модельная микрозадача`));
  loop.timeout(() => console.log(`оборот ${loop.turn}: модельный таймер`), 0);
});
loop.run();
console.log(`оборот ${loop.turn}: loop.run() вернулся`);

Последней — позже даже той строки, что стоит за loop.run(). А счётчик оборотов в ней замер на двойке: цикл давно кончился, оборотов больше не будет, и число в строке говорит не «когда выполнилось», а «чем всё закончилось». Модель здесь не соврала, она просто ни при чём: настоящий промис её миру не принадлежит. Соврал бы тот, кто по этому выводу стал бы рассуждать о порядке в Node.

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

Работает правило и в обратную сторону, как приём чтения. Открыли чужую модель, увидели в её примерах настоящий промис рядом с модельными вызовами — значит, вывод рассказывает про среду, а про модель не доказывает ничего. Проверять дальше не обязательно: одного этого хватает, чтобы не верить выводам.

Второе враньё нечестного планировщика опаснее первого, потому что выглядит как забота о порядке. await fn() читается как «дождаться, пока колбэк закончит»: с синхронным колбэком разницы не видно — он и так кончается сразу. А если колбэк асинхронный, то есть такой, какими пишут обработчики запросов?

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

// три работы ждут фазы опроса: запрос, который ждёт базу, сосед и сам ответ базы
let ответить;
const ответБазы = new Promise((resolve) => {
  ответить = resolve;
});

fake.io(async () => {
  console.log('/отчёт: жду ответ базы');
  await ответБазы;
  console.log('/отчёт: отчёт готов');
});
fake.io(() => console.log('/пинг: отвечаю сразу'));
fake.io(() => {
  console.log('байты от базы разобраны');
  ответить();
});

fake.run();
console.log('строка после fake.run()');

Две. Цикл встал на первом же обработчике: тот ждёт ответ базы, а ответ базы стоит в очереди той же фазы опроса, до которой ход уже не дойдёт. /пинг не обслужен, байты не разобраны, процесс жив и не делает ничего — при том что работа лежит прямо перед ним. Заодно видна и вторая половина беды: строка за fake.run() напечаталась сразу. Асинхронный run вернул промис, а не результат, и мир модели перестал быть замкнутым — снаружи цикла теперь видно его середину.

В Node такая программа работает, и это не мелочь, а смысл всей платформы: ждущее соединение не занимает ни потока, ни цикла. Повторим сюжет настоящим node: обработчик setImmediate с await внутри, сосед по фазе проверки и таймер, который приносит ответ. Прогноз: где в выводе окажется вторая строка ждущего обработчика — сразу за первой или в самом конце?

// Обработчик ждёт ответ базы, а ответ приносит таймер. Где в выводе окажется
// сосед по фазе проверки и где — продолжение ждущего обработчика?

let ответить;
const ответБазы = new Promise((resolve) => {
  ответить = resolve;
});

setImmediate(async () => {
  console.log('/отчёт: жду ответ базы');
  await ответБазы;
  console.log('/отчёт: отчёт готов');
});

setImmediate(() => console.log('/пинг: отвечаю сразу'));

setTimeout(() => {
  console.log('фаза сроков: ответ базы разобран');
  ответить();
}, 10);

/отчёт: жду ответ базы
/пинг: отвечаю сразу
фаза сроков: ответ базы разобран
/отчёт: отчёт готов

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

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

// Цикл не смотрит на то, что вернул колбэк, — а вернул он отклонённый промис.
// Что из этого выйдет для соседа по фазе проверки и для кода выхода?

setImmediate(async () => {
  console.log('/отчёт: начал, жду базу');
  throw new Error('база не ответила');
});

setImmediate(() => console.log('/пинг: отвечаю сразу'));

/отчёт: начал, жду базу
file://<пример>/throw.mjs:6
  throw new Error('база не ответила');
        ^

Error: база не ответила
    at Immediate.<anonymous> (file://<пример>/throw.mjs:6:9)
    at <внутренние кадры node>

Node.js v<версия>

Признак тот же, что и у первого вранья, и ищется тем же поиском: await внутри самого планировщика. В первый раз он переставил порядок, во второй — остановил цикл. Строка одна и та же.

Из этих двух ошибок выводятся три вопроса, которые стоит задавать любой модели — чужой в статье, своей в черновике. На первые два отвечает чтение кода за минуту.

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

Ни один из этих долгов не мешает модели отвечать на вопрос, ради которого она собрана: что за чем идёт внутри колбэка. Дальше её придётся поставить рядом с настоящим libuv и посмотреть, где совпадение кончается, — это статья «Настоящий цикл, libuv и пул потоков». А перед ней мы вынесем из цикла то, чему в нём не место вовсе: «Заблокировать цикл и вынести счёт в отдельный поток».

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

И последнее, ради чего всё это затевалось. Модель полезна не тем, что похожа, а тем, что её можно проверить — прогнозом перед запуском и сверкой с настоящим node после. Похожесть проверить нечем, и именно она подводит: нечестный планировщик был похож на настоящий цикл гораздо больше нашего — у него и промисы настоящие, и асинхронность честная на вид. Просто отвечал он не на тот вопрос.

Хорошая модель отвечает не на все вопросы, а на один — и прямо говорит, на какой. Та, что отвечает на все, просто не сообщила, где перестала знать.