Щач будет наркоманский вопрос, конечно. Когда epoll_wait вернулся из ядра и принёс пачку событий, почему он НЕ вернулся сразу же, когда случилось самое первое событие с первым сокетом, а позволил себе постоять в ядре и подождать ещё? Точнее так: допустим я ядро и пришёл какой-то пакет, относящийся к сокету процесса N. Как мне понять - бежать сразу будить процесс N на тему одного сокета или подождать - вдруг в следующие микросекунды навалит ещё пакетов про другие сокеты ЭТОГО ЖЕ процесса и я смогу сходить в N 1 раз оптом?
Ясно, что вопрос в ядре так не ставится, а возврат epoll_wait сразу с пачкой сокетов скорее следствие того, что ядро видит события от сетевухи тоже сразу оптом, оптом рассовывает по сокетам и потом уже смотрит какие бы процессы разбудить. И вообще работать над пакетами событий выгоднее, а не контекстсвитчить туда-сюда - это ясно. Но это все равно лишь дебильные догадки, хотелось бы почитать про сабж детальнее. Ядро разгребает накопившиеся события, относящиеся к одному процессу, не чаще фиксированного интервала, типа 1 миллисек? Сетевуха сгружает тыщи пакетов за одно прерывание? Ядро пытается контекстсвитчить не чаще N микросекунд? В общем, что является причиной того, что epoll_wait() в принципе способен вернуться сразу с пачкой евентов и его не колбасит на каждое. В то же время, если сокетов будет 10К и событие произойдёт только на 1, он вернутся достаточно шустро. Хотя наверное не так шустро, как в DPDK мире и прочем подобном?
