В отличие от [блокирующего](Блокирующие%20вызовы.md) ввода-вывода, вместо того, чтобы заблокироваться, любая операция завершается немедленно. Если данные не готовы, возвращается специальный код ошибки, по которому понятно, что следует попробовать вызов позднее. При таком варианте мы можем из одного потока выполнять несколько сетевых операций одновременно. Но, т.к. неизвестно, готов ли сокет к вводу-выводу, пришлось бы обращаться к каждому сокету по очереди с соответствующими запросами и, по сути, крутиться в вечном цикле, что неэффективно. Необходим механизм опроса готовности, в который мы могли бы запустить все сокеты, а он бы сообщал нам, которые из них готовы к вводу-выводу. С готовыми мы провели бы все нужные операции, после чего могли бы заблокироваться, ожидая сокетов, снова готовых к вводу-выводу. Таких механизмов опроса готовности несколько, они отличаются производительностью, деталями, но обычно он находится "под капотом" и нам не виден.
Как сделать неблокирующийся ввод-вывод? Мы соединяем опрос готовности и операции ввода-вывода с теми и только теми сокетами, которые сегодня готовы. Опрос готовности у нас блокируется до тех пор, пока не появятся какие-то данные хотя бы в одном сокете.
Второй вопрос по поводу того, что расположено "под капотом" – это вопрос многозадачности. Как мы можем обеспечить одновременную обработку нескольких запросов (мы договорились, что нам это необходимо)?
Есть 3 базовых варианта:
- Выделить отдельный [процесс ОС](Процесс%20ОС.md) на обработку каждого запроса.
- Если запрос упадет, то это не повлияет на остальные процессы
- Между процессами нет ничего общего. Общение между процессами не тривиально.
- Так работает PostgresSQL
- [Поток процесса ОС](Поток%20процесса%20ОС.md). В рамках одного процесса порождается несколько потоков.
-О потоках знает ОС, она умеет разбрасывать их между процессорами.
- Нити легче чем процессы. Можем породить больше нитей, чем процессов.
