Комментарии 6
Но тут пример статьи, которая ещё больше запутает начинающего программиста, чем даст ему опору. В самой книге примеры весьма годные и книгу к прочтению рекомендую, но вот примеры вырванные из контекста задач очень плохо влияют и путают сильно.
Вместо того чтобы постоянно запрашивать "есть ли обновления? а как насчет сейчас? что теперь?", мы лучше просто спросим ядро Linux "эй, вот 100 файловых дескрипторов. Скажи мне, когда один из них будет обновлен!".
Но...но...но ведь все три механизма именно что и спрашивают ядро - есть ли обновления в списке дескрипторов.
Даже epoll_wait требует непосредственного вызова, что бы получить информацию о дескрипторах, которые обновились.
Единственный действительно асинхронный механизм - это микрософтовский IOCP.
Не совсем верно, все эти три механизма просят ядро вернуть управление в юзерспейс, когда произойдёт обновление. Это выгодно отличается от того, что мы с некоторой периодичностью долбим ядро системными вызовами для проверки состояния дескриптора (или дескрипторов), впустую тратя циклы CPU на "нырки" из юзерспейса в кернелспейс и обратно.
Ближайший аналог IOCP, насколько я понимаю, - новый линуксячий механизм io_uring.
Не совсем верно, все эти три механизма просят ядро вернуть управление в юзерспейс
Всё верно, только это не совсем асинхронный ввод-вывод
В информатике асинхронный ввод/вывод является формой неблокирующей обработки ввода/вывода, который позволяет процессу продолжить выполнение не дожидаясь окончания передачи данных.
При вызове всех трёх происходит блокировка потока вызова до наступления события. Возможны трюки с NO_WAIT конечно, но в этом случае
мы с некоторой периодичностью долбим ядро системными вызовами для проверки состояния дескриптора (или дескрипторов), впустую тратя циклы CPU на "нырки" из юзерспейса в кернелспейс и обратно
io_uring
кстати, про него забыл, давно хочу поиграться и посмотреть что за зверь, да руки не доходят, спасибо, что напомнили.
Всё верно, только это не совсем асинхронный ввод-вывод
В большинстве случаев приложению (например, типичному серверу) больше ничего и не требуется делать, кроме как обрабатывать ввод-вывод, поэтому для него будет логично пробуждаться ядром в момент появления событий ввода-вывода, обрабатывать их, целиком или частично (тут могут помочь корутины, которые есть во многих ЯП) и снова засыпать до появления этих событий.
Кроме того, вы правы, в подавляющем большинстве случаев такие серверы используют на сокетах флажок O_NONBLOCK, благодаря чему непосредственный ввод-вывод (например, отправка ответа клиенту) никогда не будет блокироваться.
кстати, про него забыл, давно хочу поиграться и посмотреть что за зверь, да руки не доходят, спасибо, что напомнили.
Пожалуйста. Я по нему проводил открытый урок, может, поможет глубже разобраться в теме.
Кроме того, из похожих на IOCP есть механизм POSIX AIO, но он редко используется из-за бед с башкой производительностью, т.к. под капотом банально реализован как фоновый тред, асинхронно перемалывающий запросы на ввод-вывод.
Асинхронный ввод-вывод в Linux: select, poll и epoll