Исправление pathfinder, (текущая версия) :
А дальше дискуссия набрала обороты.
Это связано с тем, что приложения, обслуживающие ввод-вывод (и не только), там где надо дожидаться определенных событий (готовность для чтения/записи, запрос на установление соединения и т. д.) более-менее гармонично могут быть написаны двумя разными путями, ну или идеологиями:
1. Опирается на многопоточность и блокирующий ввод/вывод. Ожидание достигается засыпанием процесса во множестве разных мест программы. Примером таких программ может служить любой многопоточный TCP сервер. Инфраструктура ввода/вывода «размазана» по коду.
2. Опирается на неблокирующий ввод/вывод. Может легко обслуживать множество соединений в рамках одного потока. Как правило, процесс засыпает в строго определенном месте, внутри тела процедуры, так называемого «цикла обработки сообщений». Скорее всего засыпает на этом самом вызове epoll(). Имеет ярко выраженную инфраструктуру, берущую на себя всю рутину по обслуживанию ввода/вывода и ожиданию событий.
99% программ используют одну из этих двух идеологий. Если речь идет именно о неблокирующем вводе/выводе, то само собой должно подразумеваться, что есть какая-то обособленная инфраструктура ввода/вывода; самописная или на базе какой-нибудь библиотеки типа boost::ASIO. Эта самая инфраструктура в ходе своего функционирования естественным образом должна решать проблему, которая возникла у ТС.
Выводы:
Либо у ТС какое-то маленькое простенькое приложение, от которого много не требуется, пускай вызывает usleep(). Криво, но зато работает.
Либо ТС должен работать с блокируемыми сокетами.
Либо ТС должен сделать сам/взять готовую инфраструктуру ввода/вывода, понять как она работает и не задавать глупых вопросов.
Либо ТС нашел какой-то свой, «особенный» путь. Тогда ему никто не поможет, и он должен бороться один со своими проблемами.
Исправление pathfinder, :
А дальше дискуссия набрала обороты.
Это связано с тем, что приложения, обслуживающие ввод-вывод (и не только), там где надо дожидаться определенных событий (готовность для чтения/записи, запрос на установление соединения и т. д.) более-менее гармонично могут быть написаны двумя разными путями, ну или идеологиями:
1. Опирается на многопоточность и блокирующий ввод/вывод. Ожидание достигается засыпанием процесса во множестве разных мест программы. Примером таких программ может служить любой многопоточный TCP сервер. Инфраструктура ввода/вывода «размазана» по коду.
2. Опирается на неблокирующий ввод/вывод. Может легко обслуживать множество соединений в рамках одного потока. Как правило, процесс засыпает в строго определенном месте, внутри тела процедуры, так называемого «цикла обработки сообщений». Скорее всего засыпает на этом самом вызове epoll(). Имеет ярко выраженную инфраструктуру, берущую на себя всю рутину по обслуживанию ввода/вывода и ожиданию событий.
99% программ используют одну из этих двух идеологий. Если речь идет именно о неблокирующем вводе/выводе, то само собой должно подразумеваться, что есть какая-то обособленная инфраструктура ввода/вывода; самописная или на базе какой-нибудь библиотеки типа boost::ASIO. Эта самая инфраструктура в ходе своего функционирования естественным образом должна решать проблему, которая возникла у ТС.
Выводы:
Либо у ТС какое-то маленькое простенькое приложение, от которого много не требуется, пускай вызывает usleep(). Криво но зато работает.
Либо ТС должен работать с блокируемыми сокетами.
Либо ТС должен сделать сам/взять готовую инфраструктуру ввода/вывода, понять как она работает и не задавать глупых вопросов.
Либо ТС нашел какой-то свой, «особенный» путь. Тогда ему никто не поможет, и он должен бороться один со своими проблемами.
Исходная версия pathfinder, :
А дальше дискуссия набрала обороты.
Это связано с тем, что приложения, обслуживающие ввод-вывод (и не только), там где надо дожидаться определенных событий (готовность для чтения/записи, запрос на установление соединения и т. д.) более-менее гармонично могут быть написаны двумя разными путями, ну или идеологиями:
1. Опирается на многопоточность и блокирующий ввод/вывод. Ожидание достигается засыпанием процесса во множестве разных мест программы. Примером таких программ может служить любой многопоточный TCP сервер. Инфраструктура ввода/вывода «размазана» по коду.
2. Опирается на неблокирующий ввод/вывод. Может легко обслуживать множество соединений в рамках одного потока. Как правило, процесс засыпает в строго определенном месте, внутри тела процедуры, так называемого «цикла обработки сообщений». Скорее всего засыпает на этом самом вызове epoll(). Имеет ярко выраженную инфраструктуру, берущую на себя всю рутину по обслуживанию ввода/вывода и ожиданию событий.
99% программ используют одну из этих двух идеологий. Если речь идет именно о неблокирующем вводе/выводе, то само собой должно подразумеваться, что есть какая-то обособленная инфраструктура ввода/вывода; самописная или на базе какой-нибудь библиотеки типа boost::ASIO. Эта самая инфраструктура в ходе своего функционирования естественным образом должна решать проблему, которая возникла у ТС.
Выводы: Либо у ТС какое-то маленькое простенькое приложение, от которого много не требуется, пускай вызывает usleep(). Криво но зато работает.
Либо ТС должен работать с блокируемыми сокетами.
Либо ТС должен сделать сам/взять готовую инфраструктуру ввода/вывода, понять как она работает и не задавать глупых вопросов.
Либо ТС нашел какой-то свой, «особенный» путь. Тогда ему никто не поможет, и он должен бороться один со своими проблемами.