Select() vs блокирующие сокеты

Здравствуйте,

Подскажите пожалуйста, в чем принципиальное отличие работы с сокетами с помощью Select() и в обычном блокирующем режиме с потоками ?

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


-Select() - якобы предоставляет более "лучший" метод, он не блокирует поток и может в одном потоке обрабатывать те же 100 соединений, как я понял, достаточно грубо и условно, но эти 100 сокетов помещаются в массив и при вызове Select() - они тупо перебором опрашиваются на предмет завершения операций - или Send() или то, что сокет получил данные и можно вызвать Recv().

Но в чем принципиальное отличие то ?? Ведь - это все равно нужно в цикле постоянно вызывать Select(), а Select() уже будет вызвать свой цикл прохода о сокетам - и получится - та же самая трата времени CPU ? Разве нет ?
И кстати само "кручение" Select в цикле и сам вызов Select в итоге не является ли блокирующим ? Или его нужно держать запущенным в отдельном от основного - потоке ?


И если не сложно можете пожалуйста подсказать, какой сакральный смысл структуры timeval ? То в Select передается некий таймаут, но зачем и на что он влияет ?? Зачем Select`у таймаут ? Или в каких случаях он нужен ?
Нам же нужно постоянно проверять сокеты на предмет готовности к операции, зачем может пригодится таймаут?

0

С poll кошерней. Не придется по потоку на каждого клиента заводить (а то ведь не ровен час, количество PID'ов выйдет за пределы uint16_t).

0

Сообщение от Optimus11 он не блокирует поток и может в одном потоке обрабатывать те же 100 соединений

это неверно.
и из этого следуют дальнейшие ошибочные выводы, что select не лучше.

Сообщение от Optimus11 Ведь - это все равно нужно в цикле постоянно вызывать Select(), а Select() уже будет вызвать свой цикл прохода о сокетам - и получится - та же самая трата времени CPU ? Разве нет ?

нет, select блокирует выполнение до того, как один или несколько сокетов из read_fds, write_fds или except_fds не станут "активны", то есть получат событие.
либо, второй вариант выхода из функции select - по таймауту, указанному в последнем параметре.
функция select является системным вызовом, поэтому нет, она не крутит внутри никаких циклов, а срабатывает по событию в ядре ОС и не ест CPU, пока ждёт событий.

хотя select не лишён недостатков.
проблема select заключается в том, что после выхода из неё нужно пройти по всем переданным сокетам и проверить, какой из них выставлен.
это даёт O(N) сложность обработки результатов.
poll, к слову, в этом плане ничем не лучше. ЕМНИП, он работает чуть быстрее, но проверять придётся также перебором и проверкой событий.

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

P.S. на винде лучше всего использовать IOCP, на линуксе epoll, на FreeBSD kqueue, но для начального понимания сойдёт и select или poll.

1

Сообщение от GbaLog- poll, к слову, в этом плане ничем не лучше.

Зато poll не требует, чтобы все файловые дескрипторы строго подряд были! А select требует. В общем, если есть два набора файловых дескрипторов, и надо лишь один опрашивать, то select будет постоянно ложные срабатывания давать, когда fd из другого набора окажется в диапазоне 0..fdmax.
Для низконагруженного сервера действительно лучше будет по одному потоку выделять на каждого клиента - там можно и select'ом проверять активность (а если не нужно асинхронно клиенту что-то отправлять, то даже блокирующий read использовать). А вот при высокой нагрузке удобней всего poll (именно poll, а не epoll; хотя, это, наверное, на любителя). Как только закрылся какой-то сокет, вместо него в массив дескрипторов помещаем дескриптор последнего и уменьшаем количество.
Конечно, если бы poll принимал не массив, а связный список, было бы легче: не нужно было бы лишних манипуляций с дескрипторами проводить, когда один закрылся.

0

Сообщение от GbaLog- функция select является системным вызовом, поэтому нет, она не крутит внутри никаких циклов, а срабатывает по событию в ядре ОС и не ест CPU, пока ждёт событий.

То есть ОС оповещает -->Select, что на каком то сокете из массива произошло событие, но не оповещает на каком и после этого сообщение Select как раз уже проходится циклом по массиву сокетом - ища на каком сокете/сокетах произошло событие и после нахождение возвращает - данные об этом сокете ?

Сообщение от GbaLog- либо, второй вариант выхода из функции select - по таймауту, указанному в последнем параметре.

Если я более менее правильно выше понял работу Select - то назначение таймаута не понятно. Зачем выходит из Select по таймауту, если грубо говоря моя цель с которой я вызывал Select - это узнать произошли ли события на сокетах и если да, то на каких. Если я выйду по таймауту, то это значит, что Select`у не пришло сообщение от ОС о событиях на сокете и Select завершился просто так и мне его же опять нужно вызвать. Как то этот момент не понятен совсем.

0

Если работать без поллинга тем же select'ом, то как писать клиенту?
select и нужен для того, чтобы проверять, нет ли сведений от клиента, не блокируя основной поток. Если что-то клиенту нужно отправить - отправляем, а потом опять поллинг вызываем.

0

Сообщение от Optimus11 Select`у не пришло сообщение от ОС о событиях на сокете и Select завершился просто так и мне его же опять нужно вызвать

Допустим вы хотите отключить клиента, если от него долго нет запросов. Как сделаете подобное без тайм-аута? А так довольно удобно, вышли по тайм-ауту, проверили время и опять поставили ожидание.

0

Сообщение от Optimus11 То есть ОС оповещает -->Select, что на каком то сокете из массива произошло событие, но не оповещает на каком и после этого сообщение Select как раз уже проходится циклом по массиву сокетом - ища на каком сокете/сокетах произошло событие и после нахождение возвращает - данные об этом сокете ?

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

0