Как работает выбор сокета()?

Каждый цикл мониторинга означает, что всякий раз, когда операционная система по существу справляется с этим, она может периодически проверять дескрипторы или обрабатывать их с помощью событий или прерываний. Когда данные получены в дескрипторе файла сокета, файл дескриптора заполняется данными, и процесс, который ожидал его, информируется. Это не всегда происходит сразу, так как процесс не пробуждается немедленно, он просто возвращается в очередь готовности к запуску (поскольку он был заблокирован вызовом select). Если вызов select терпит неудачу (данные не получены в течение тайм-аута), то срабатывает таймер и возвращает процесс в очередь выполнения.

Да, fd в FD_SET 0-26 проверяются или контролируются. Это просто для того, чтобы установить верхнюю границу поиска файловых дескрипторов. IIRC это связано с тем, что тип fd_set реализован внутри как набор битов, поскольку легче указывать индексы, поскольку это может сэкономить место. Я могу ошибаться в предыдущем утверждении, так как я давно не посещал этот код в glibc.

select выбирает, какие fd смотреть, основываясь на наборах fd, которые вы передаете (readfds, writefds, exceptfds). Наборы обычно реализуются как битовые векторы, поэтому select будет сканировать вектор, чтобы увидеть, какие fds выбраны. В качестве оптимизации вы передаете количество fd для сканирования, чтобы select не приходилось просматривать все fd до FD_SETSIZE (что может даже не совпадать в разных единицах компиляции).

select — довольно дорогой вызов из-за сканирования и необходимости сброса наборов после каждого вызова select. На многих платформах select просто реализуется поверх системного вызова poll, который предлагает более эффективный интерфейс для ожидания файловых дескрипторов.