epoll и висящие соединения

однако вполне логично предположить число 65535 для принятых сокетов

65535 портов одного клиента с одного адреса, допустим, 127.0.0.1, один порт сервера и его адрес, дальше — _ещё_ (прямо одновременно) 65535 портов другого клиента с _другого_ адреса 127.0.0.2 — никаких конфликтов, на сервере может быть открыто намного больше сокетов (соединений) чем 65535.

Зачем отдельный epoll? Есть у тебя epoll в котором твой миллион соединений, в него добавляешь дескриптор таймера и по приходу события на чтение - проверяешь соединения, по каждому соединению сбрасываешь счетчик принятых пакетов, если он 0 значит пакетов не было, закрываешь соединение. Реализация простейшая и удобная, не нужны межпоточные синхронизации и прочее. И да, пробежать фором по 1e6 интов (кол принятных пакетов) это ваще пшик, а не нагрузка.

в него добавляешь дескриптор таймера и по приходу события на чтение - проверяешь соединения

те таймер один и приняв его пробегать по всем соединениям? это будет аналогично отдельному треду с полным перебором. я думал создать каждому сокету по таймеру и запихать таймеры в отдельный epoll чтобы не путать от кого event от сокета или от таймера

И да, пробежать фором по 1e6 интов (кол принятных пакетов) это ваще пшик, а не нагрузка.

Отличны придумал способ прибития всех кешей CPU. Интересно, в этой теме много ещё будет бредовых идей...

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

Если там хоть сколько то сложная обработка соединений - твой кэш будет меняться только так.

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