私は最近、複数のスレッドがリッスンしている UNIX ドメイン ソケットでポーリングし、接続を受け入れるシナリオをテストしました。すべてのスレッドは、poll() システム コールを使用してウェイクアップしました。
これは、ディストリビューション ビルドではなく、Linux カーネルのカスタム ビルドだったので、それを変更するカーネル構成オプションがあるのかもしれませんが、それが何であるかはわかりません。
epoll は試していません。
何年もの間、ほとんどの unix/linux カーネルは、accept(2) への応答をシリアル化します。つまり、1 つの開いているファイル記述子に対して複数のスレッドが accept(2) でブロックしている場合、1 つのスレッドのみが起動されます。
OTOH、あなたが説明したように、多くの (すべてではないにしても) カーネルには、select-accept パターンで雷鳴の群れの問題がまだあります。
問題の存在を確認するための簡単なスクリプト ( https://gist.github.com/kazuho/10436253 ) を作成したところ、Linux 2.6.32 と Darwin 12.5.0 (OS X 10.8 .5).
これは非常に古い問題であり、ほとんどの場合、もはや存在しません。 Linux カーネル (過去数年間) は、パケットを処理してネットワーク スタックにルーティングする方法に多くの変更があり、低レイテンシと公平性 (つまり、飢餓を最小限に抑える) の両方を確保するための多くの最適化が含まれています。
そうは言っても、select システムには、その API を使用するだけで、多くのスケーラビリティの問題があります。多数のファイル記述子がある場合、select 呼び出しのコストは非常に高くなります。これは主に、システム コールとの間でやり取りされる FD セットを構築、チェック、および維持する必要があるためです。
現在、非同期 IO を実行するための推奨される方法は、epoll を使用することです . API ははるかにシンプルで、さまざまなタイプの負荷 (多数の接続、大量のスループットなど) にわたって非常にうまくスケーリングします。