Recientemente vi probado un escenario en el que varios subprocesos sondearon en un socket de dominio Unix de escucha y luego aceptaron la conexión. Todos los subprocesos se despertaron usando la llamada al sistema poll().
Esta fue una compilación personalizada del kernel de Linux en lugar de una compilación de distribución, por lo que tal vez haya una opción de configuración del kernel que lo cambie, pero no sé cuál sería.
No probamos epoll.
Durante años, la mayoría de los núcleos de Unix/Linux serializan la respuesta a accept(2), en otras palabras, solo se activa un subproceso si más de uno bloquean accept(2) contra un solo descriptor de archivo abierto.
OTOH, muchos kernels (si no todos) todavía tienen el problema del rebaño atronador en el patrón de selección y aceptación como usted describe.
Escribí un script simple (https://gist.github.com/kazuho/10436253) para verificar la existencia del problema y descubrí que el problema existe en Linux 2.6.32 y Darwin 12.5.0 (OS X 10.8 .5).
Este es un problema muy antiguo, y en su mayor parte ya no existe. El kernel de Linux (durante los últimos años) ha tenido una serie de cambios en la forma en que maneja y enruta los paquetes a la pila de la red, e incluye muchas optimizaciones para garantizar una baja latencia y equidad (es decir, minimizar el hambre).
Dicho esto, el seleccionar El sistema tiene una serie de problemas de escalabilidad simplemente por medio de su API. Cuando tiene una gran cantidad de descriptores de archivos, el costo de una llamada selecta es muy alto. Esto se debe principalmente a tener que crear, verificar y mantener los conjuntos de FD que se pasan hacia y desde la llamada del sistema.
Hoy en día, la forma preferida de hacer E/S asíncrona es con epoll . La API es mucho más simple y escala muy bien en varios tipos de carga (muchas conexiones, mucho rendimiento, etc.)