Блокирующий и неблокирующий ввод-вывод

Блокирующий системный вызов приостанавливает вызывающий поток, пока операция не сможет продолжиться. Если вызвать recv() для сокета без данных, ядро усыпит поток до поступления байтов.

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

При блокирующем вводе-выводе один зависший клиент блокирует весь поток. Классическое решение — отдельный поток или процесс для каждого соединения.

Это работает до определённого предела, но 10 000 потоков означают 10 000 стеков, частое переключение контекста и большие накладные расходы планировщика. Это знаменитая проблема C10k, подтолкнувшая серверы к событийным архитектурам.

Неблокирующий сокет никогда не засыпает. Если вызов не может завершиться немедленно, он сразу возвращает -1 и устанавливает для errno значение EAGAIN или EWOULDBLOCK.

Теперь ваш код должен сам повторить попытку позже. Благодаря этому один поток может обслуживать множество сокетов, не застревая ни на одном из них.

Чтобы перевести дескриптор в неблокирующий режим, добавьте флаг O_NONBLOCK с помощью fcntl(). Сначала всегда считывайте текущие флаги, затем добавляйте к ним этот бит операцией OR, чтобы не затереть остальные настройки.

Та же вспомогательная функция используется для прослушивающих сокетов, принятых клиентских сокетов и каналов.

В неблокирующем вводе-выводе частичные операции становятся обычным явлением. Вызов recv() может вернуть меньше запрошенных байтов, а send() — принять только часть вашего буфера.

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

Наивный способ использовать неблокирующие сокеты — постоянно обходить все сокеты и повторять попытки. Такое активное ожидание загружает CPU на 100 %, даже когда ничего не происходит.

На самом деле нужно попросить ядро: «сообщи, какие дескрипторы готовы, и позволь мне спать до этого момента». Именно это и обеспечивает уведомление о готовности.

Мультиплексирование ввода-вывода позволяет одному потоку одновременно ждать множество дескрипторов и просыпаться, только когда готов хотя бы один из них. Ядро выполняет наблюдение за вас.

Классические интерфейсы — select() и poll(). Они работают, но при каждом вызове повторно проверяют каждый дескриптор, что при большом масштабе становится дорого.

И select(), и poll() имеют сложность O(n): каждый вызов передаёт ядру полный набор дескрипторов, ядро сканирует их все, а затем вы снова сканируете их все, чтобы найти готовые.

select() также ограничен примерно значением FD_SETSIZE — часто 1024. Для тысяч соединений эти накладные расходы становятся доминирующими.

epoll — масштабируемое решение Linux. Вы один раз регистрируете интерес к дескриптору, а ядро поддерживает внутреннюю структуру данных, отслеживающую готовность.

Каждое ожидание возвращает только действительно готовые дескрипторы, поэтому затраты зависят от активных соединений, а не от их общего числа. Благодаря этому стоимость обработки примерно равна O(1) на готовое событие.

epoll и неблокирующие сокеты работают в связке. epoll сообщает, что дескриптор готов, а неблокирующие вызовы позволяют полностью обработать его, не переходя в ожидание.

Всегда устанавливайте O_NONBLOCK на сокетах, передаваемых epoll. Иначе ложное пробуждение или частичное чтение может заблокировать единственный поток цикла обработки событий.

Представьте сервер в виде цикла: заблокироваться в epoll_wait(), получить небольшой список готовых дескрипторов, выполнить неблокирующую работу с каждым и повторить.

В простое поток спит и просыпается только для настоящей работы. Теперь один поток может эффективно обслуживать десятки тысяч соединений.

Блокирующий ввод-вывод прост, но требует отдельного потока для каждого соединения, что не подходит при большом масштабе. Неблокирующий ввод-вывод немедленно возвращает результат с EAGAIN, не переходя в ожидание.

Опрос сокетов в тесном цикле расходует CPU, поэтому мы используем уведомление о готовности. select/poll имеют сложность O(n), а epoll масштабируется до многих тысяч соединений. Далее мы настроим epoll.