Краткий ответ

Event loop регистрирует сокеты в механизме мультиплексирования ввода-вывода операционной системы и ожидает уведомлений о готовности. Когда ОС сообщает, что сокет можно читать или записывать без блокировки, event loop запускает связанную с ним корутину или callback.

Это позволяет одному потоку обслуживать множество соединений. При этом сам сетевой ввод-вывод выполняется неблокирующим образом; event loop не ждёт завершения каждой операции в отдельном потоке.

Исторический контекст

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

Операционные системы предоставляют специальные механизмы мультиплексирования: например, epoll в Linux, kqueue в BSD-системах и IOCP в Windows. Асинхронные библиотеки скрывают различия между ними за интерфейсом event loop.

Постановка проблемы

Если event loop будет выполнять блокирующее чтение сокета, он остановит обработку всех остальных задач. Один медленный клиент тогда сможет задержать другие соединения, даже если их данные уже готовы.

Неверно также считать, что await сам по себе делает любую функцию неблокирующей. Асинхронная библиотека должна зарегистрировать операцию в event loop, передать управление циклу и возобновить корутину только после уведомления ОС.

Подробное решение

При ожидании сетевых данных библиотека переводит сокет в неблокирующий режим и регистрирует интерес к событию чтения. Затем корутина приостанавливается на await, а event loop начинает обслуживать другие готовые задачи.

Операционная система отслеживает состояние сокетов. Когда чтение возможно, event loop получает событие, выполняет неблокирующее чтение и передаёт полученные данные ожидающей корутине. Если доступна только часть сообщения, корутина может снова приостановиться до следующего уведомления.

В Unix-реализациях asyncio обычно используется семейство selector-based механизмов. В Windows возможна реализация на основе IOCP, где модель ближе к уведомлению о завершении операции, а не только о готовности дескриптора.

Мультиплексирование не создаёт параллельного выполнения Python-кода. В одном event loop callbacks и корутины выполняются последовательно; выигрыш возникает за счёт того, что поток не простаивает во время ожидания сети.

Минимальный пример демонстрирует типичную точку передачи управления event loop:

import asyncio

async def handle(reader, writer):
    data = await reader.read(1024)
    writer.write(data)
    await writer.drain()
    writer.close()
    await writer.wait_closed()

async def main():
    server = await asyncio.start_server(handle, "127.0.0.1", 8000)
    async with server:
        await server.serve_forever()

asyncio.run(main())

Вызов reader.read не обязан блокировать поток: если данные ещё не готовы, корутина приостанавливается, а event loop может обслуживать другие подключения. Однако обработчик не должен выполнять длительные синхронные вычисления, иначе он задержит все остальные задачи.

Ситуация из практики

В HTTP-сервисе нужно обслуживать тысячи соединений, большинство из которых простаивает в ожидании сетевых данных. Вариант с отдельным потоком на клиента проще для понимания, но увеличивает потребление памяти и стоимость переключения контекста. Вариант с одним event loop экономичнее для большого числа I/O-bound соединений, но требует неблокирующих библиотек и дисциплины: синхронные вызовы вроде длительного чтения файла или вычисления должны выноситься из event loop.

Был выбран asyncio-сервис с асинхронным сетевым стеком. Это позволило одному потоку эффективно обслуживать соединения, а CPU-bound операции были вынесены в отдельный пул процессов. Результатом стало отсутствие блокировки event loop сетевыми ожиданиями при сохранении отдельного механизма для тяжёлых вычислений.

Что кандидаты часто упускают

Вопрос: Гарантирует ли уведомление о готовности, что операция чтения вернёт всё запрошенное сообщение?

Ответ: Нет. Готовность означает, что чтение возможно без блокировки, но доступен может быть только фрагмент данных. TCP не сохраняет границы сообщений, поэтому приложение должно накапливать данные и самостоятельно определять границу протокольного сообщения.
Вопрос: Что произойдёт, если после получения сетевого события callback начнёт длительное вычисление?

Ответ: В однопоточном event loop вычисление займёт поток цикла и задержит обработку всех других событий. Сетевые данные могут уже находиться в буферах ОС, но корутины не возобновятся, пока callback не завершится. CPU-bound работу обычно передают пулу потоков или процессов с учётом ограничений GIL и стоимости передачи данных.
Вопрос: Чем отличается ожидание готовности сокета от ожидания завершения операции ввода-вывода?

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