Nedávno jsem viděl testovaný scénář, kde se několik vláken dotazovalo na naslouchající soket unixové domény a poté přijalo připojení. Všechna vlákna se probudila pomocí systémového volání poll().
Toto bylo vlastní sestavení linuxového jádra spíše než sestavení distro, takže možná existuje možnost konfigurace jádra, která to změní, ale nevím, co by to bylo.
Epoll jsme nezkoušeli.
Po mnoho let většina unixových/linuxových jader serializuje odpověď na accept(2)s, jinými slovy, pouze jedno vlákno se probudí, pokud více než jedno blokuje accept(2) proti jedinému otevřenému deskriptoru souboru.
OTOH, mnohá (ne-li všechna) jádra mají stále problém s hromovým stádem ve vzoru select-accept, jak popisujete.
Napsal jsem jednoduchý skript ( https://gist.github.com/kazuho/10436253 ), abych ověřil existenci problému, a zjistil jsem, že problém existuje na linuxu 2.6.32 a Darwinu 12.5.0 (OS X 10.8 .5).
Toto je velmi starý problém a z velké části již neexistuje. Linuxové jádro (za posledních několik let) prošlo řadou změn ve způsobu, jakým zpracovává a směruje pakety do síťového zásobníku, a obsahuje mnoho optimalizací pro zajištění nízké latence a spravedlnosti (tj. minimalizace hladovění).
To znamená, vybrat systém má řadu problémů se škálovatelností jednoduše prostřednictvím jeho API. Když máte velký počet deskriptorů souborů, náklady na výběrové volání jsou velmi vysoké. To je primárně způsobeno nutností vytvářet, kontrolovat a udržovat sady FD, které jsou předávány do a ze systémového volání.
V dnešní době je preferovaný způsob, jak provádět asynchronní IO, pomocí epoll . Rozhraní API je mnohem jednodušší a velmi dobře se škáluje napříč různými typy zatížení (mnoho připojení, velká propustnost atd.)