Есть ли альтернатива select() для клиентской стороны соединения с неблокируемым сокетом TCP?Альтернативы select() на стороне клиента
select() в основном для нескольких подключений, но у моего клиента только одно соединение. В результате я спросил себя, есть ли альтернативная функция для распознавания ввода-вывода в одном сокете. Скорее всего, это будет быстрее, и мне не понадобится вся обработка fd_set.
В клиенте вы должны использовать select(), и он будет не быстрее, если вы используете select только для одного сокета.
Кстати, select() не для нескольких подключений ... в реальном мире из-за проблем с производительностью. Только для вашей информации, посмотрите на /dev/poll/epoll()/kqueue() и io completion port для Windows.
Select() помогает вам отслеживать как события чтения и записи (и события исключения) одним выстрелом, так и делает вещи масштабируемыми, а не проверять приложение (поскольку оно не блокирует). Вероятно, вам следует уточнить, какова цель вашего конечного дизайна. Конечно, как сказал кто-то, имея два потока, один для чтения и записи мог бы сделать то же самое. На самом деле, если у вас более высокая рабочая нагрузка, вы можете выйти за пределы двух и фактически сохранить пул потоков.
Возможно, у вас есть чтение ниток, и вам просто нужно проверить специальное значение или что-то в этом роде – Alexis
Если вы не хотите активно проводить опрос через 'select' /' poll'/etc., То вы можете использовать сигналы с обработчиком сигнала SIGIO. Или используйте поток для подключения и блокируйте сокеты в потоке. –
Если у вас есть только один дескриптор файла для мониторинга, вы можете использовать неблокирующие вызовы 'read()', если он является сокетом TCP, а не сокетов UDP. Неблокирующее 'read()' немедленно вернется, если не будет данных для чтения, и ваша программа будет работать с жизнью. Если вы хотите его заблокировать, просто используйте 'read()'. Вы должны использовать 'fcntl()' для установки неблокирующего атрибута в дескрипторе файла. –