Одна итерация цикла под микроскопом: ready-очередь, опрос селектора, куча таймеров и какие await реально уступают

Одна итерация под микроскопом

Корутинами и TaskGroup вы уже пользуетесь ежедневно (юнит про конкурентность); этот урок открывает капот. Дефолтный цикл — читаемый круг вокруг трёх структур данных: FIFO ready-очередь колбэков, селектор (epoll/kqueue), следящий за дескрипторами, и куча таймеров (heapq хэндлов, отсортированных по времени). Одна итерация BaseEventLoop._run_once, упрощённо, но честно:

# форма одной итерации, упрощено из CPython asyncio
def _run_once(self):
    timeout = 0 if self._ready else self._next_timer_delay()  # None = ждать вечно
    events = self._selector.select(timeout)   # ЕДИНСТВЕННОЕ место сна цикла
    self._process_events(events)              # готовность -> колбэки в ready
    now = self.time()
    while self._scheduled and self._scheduled[0].when() <= now:
        self._ready.append(heapq.heappop(self._scheduled))    # созревшие таймеры в очередь
    ntodo = len(self._ready)                  # снимок! добавленные ВО ВРЕМЯ
    for _ in range(ntodo):                    # разгрузки ждут СЛЕДУЮЩЕЙ итерации
        self._ready.popleft()._run()

Следствия читаются прямо из кода. loop.call_soon(cb) добавляет в ready-очередь — FIFO, честно, выполнится в эту или следующую итерацию благодаря снимку ntodo (колбэк, бесконечно перепланирующий сам себя, не может заморить I/O голодом). call_later/call_at кладут TimerHandle в кучу; отменённые таймеры вычищаются лениво, так что миллион отменённых таймаутов болтается в куче, пока не сработает порог очистки. А таймаут селектора — самое элегантное место: цикл спит ровно до ближайшего таймера; ноль ready-колбэков и пустая куча означают полностью блокирующий select и ноль сожжённого CPU. Нет ни тика, ни интервала опроса, ни потока-планировщика. Цикл — это ровно этот круг, на одном потоке, навсегда.

Как на самом деле работает await — и какие await не уступают

Корутина — это генераторная машинерия в новом синтаксисе: она приостанавливается и возобновляется той же механикой фреймов, управляемой send() и throw(). Task владеет своей корутиной и ведёт её шагами: каждый шаг вызывает coro.send(None), корутина бежит, пока не завершится или не отдаст наружу pending-футуру; тогда Task вешает на футуру done-колбэк и возвращается — и этот возврат и есть передача управления циклу, потому что сам шаг был просто колбэком в ready-очереди. Когда футура разрешается, её колбэк делает call_soon(step), и круг продолжается.

Тонкость, на которой горят сеньоры: await не означает «уступить циклу». await обычной корутины — синхронный вызов на фрейм глубже. await уже завершённой футуры возвращается немедленно, без приостановки. Управление доходит до цикла, только когда await упирается во что-то действительно pending:

async def fast_path(cache, key):
    if key in cache:
        return cache[key]      # эта ветка никогда не уступает: обычный вызов
    val = await fetch(key)     # уступит, ТОЛЬКО если fetch повиснет на реальном I/O
    cache[key] = val
    return val

# Шторм 100%-х попаданий в кэш делает fast_path «асинхронным, но не уступающим»:
# каждый вызов пробегает от начала до конца внутри одного шага задачи, и цикл,
# крутящий тысячи таких попаданий, всё это время морит голодом остальные задачи.

Это и есть тонкость голодания: async-функция без pending-await выполняется как один непрерываемый колбэк. Плотный цикл таких вызовов держит loop всю свою длительность — await asyncio.sleep(0) существует ровно для того, чтобы вставить явную точку уступки в такой цикл, а урок 2 покажет, что тот же факт решает, где может приземлиться отмена.

Единственное правило — с механизмом в комплекте

Каждый учебник по asyncio говорит «не блокируй цикл». Теперь механизм виден: блокирующий вызов — requests.get, time.sleep, та самая 200-миллисекундная верификация RS256 — выполняется внутри фазы разгрузки одной итерации. Пока он идёт, итерация не возвращается к selector.select: готовность сокетов не наблюдается; таймеры (включая каждый asyncio.timeout в полёте — урок 3) лежат в куче несработавшими; новые соединения копятся в accept-бэклоге ядра. В юните про веб-сервисы вы видели, что один заблокированный воркер останавливает один запрос; здесь одна заблокированная корутина останавливает каждый запрос процесса — тот самый множитель, который превратил 200 мс верификации в общепроцессный пол p99 в 230 мс. Клапан давления — loop.run_in_executor / asyncio.to_thread: они уносят блокирующий вызов в другой поток и возвращают циклу его итерацию; урок 4 владеет математикой размеров пула и оговорками про GIL.

Детектор встроен в коробку. Debug-режим — PYTHONASYNCIODEBUG=1 или asyncio.run(main(), debug=True) — логирует каждый колбэк или шаг задачи, державший цикл дольше loop.slow_callback_duration (по умолчанию 0.1 с), с именем корутины: строка Executing took 0.213 seconds — это инцидент из Хука, находящий сам себя в стейджинге. Он же печатает трейсбеки никогда-не-await-нутых корутин до точки создания. Накладные расходы реальны, поэтому включайте его в нагрузочных тестах стейджинга, а не как прод-дефолт.

uvloop, честно

uvloop подменяет всю реализацию цикла на libuv (C-библиотека под Node.js) за тем же API: установили policy — остальное без изменений. Честные числа: порядка 2–4x пропускной способности на сокето-ёмких нагрузках — прокси, echo-подобные сервисы, много мелких фреймов — и выигрыш тает по мере того, как профиль начинает доминировать ваш собственный код хэндлеров. Он ускоряет машинерию (опрос, диспетчеризацию колбэков, чтение транспортов); инциденту из Хука он не помог бы никак, потому что цикл не был медленным — он был в заложниках. Если py-spy показывает время в вашем Python, uvloop не сдвинет ничего.