J'ai récemment vu testé un scénario dans lequel plusieurs threads interrogés sur un socket de domaine unix à l'écoute, puis ont accepté la connexion. Tous les threads se sont réveillés à l'aide de l'appel système poll().
Il s'agissait d'une version personnalisée du noyau Linux plutôt que d'une version de distribution, il existe donc peut-être une option de configuration du noyau qui la modifie, mais je ne sais pas ce que cela serait.
Nous n'avons pas essayé epoll.
Pendant des années, la plupart des noyaux unix/linux sérialisent les réponses aux accept(2), en d'autres termes, un seul thread est réveillé si plusieurs bloquent sur accept(2) contre un seul descripteur de fichier ouvert.
OTOH, de nombreux noyaux (sinon tous) ont encore le problème de troupeau tonitruant dans le modèle select-accept comme vous le décrivez.
J'ai écrit un script simple ( https://gist.github.com/kazuho/10436253 ) pour vérifier l'existence du problème, et j'ai découvert que le problème existe sur linux 2.6.32 et Darwin 12.5.0 (OS X 10.8 .5).
C'est un problème très ancien, et pour la plupart n'existe plus. Le noyau Linux (au cours des dernières années) a subi un certain nombre de changements dans la manière dont il gère et achemine les paquets vers le haut de la pile réseau, et inclut de nombreuses optimisations pour garantir à la fois une faible latence et l'équité (c'est-à-dire minimiser la famine).
Cela dit, le sélectionner système a un certain nombre de problèmes d'évolutivité simplement par le biais de son API. Lorsque vous avez un grand nombre de descripteurs de fichiers, le coût d'un appel select est très élevé. Cela est principalement dû au fait de devoir créer, vérifier et maintenir les ensembles FD qui sont transmis vers et depuis l'appel système.
De nos jours, la meilleure façon de faire des E/S asynchrones est avec epoll . L'API est beaucoup plus simple et s'adapte très bien à différents types de charge (de nombreuses connexions, beaucoup de débit, etc.)