基本レベルのイベント ループは次のようなものです。
while getNextEvent (&event) {
dispatchEvent (&event);
}
言い換えれば、それは何らかの記述のキューからイベントを継続的に取得し、そのイベントをイベント処理手順にディスパッチするループにすぎません。
すでにご存知かもしれませんが、文脈のために説明しているだけです。
さまざまなサーバーがそれを処理する方法に関しては、Apache で行われるすべての新しい接続には、その接続用に作成されたスレッドがあり、そのスレッドはその接続のみを担当しているようです。
他の 2 つのスレッドについては、「設定された」数のスレッドが実行されている可能性が高く (これは実際には負荷によって異なる場合があります)、接続はそれらのスレッドの 1 つに渡されます。つまり、任意の時点で1 つのスレッドが複数の接続を処理している可能性があります。
そのため、その場合のイベントには、適用される接続に関する詳細を含める必要があります。これにより、スレッドはさまざまな接続を互いに分離した状態に保つことができます。
どちらのオプションにも長所と短所があることは間違いありません。スレッドごとに 1 つの接続オプションを使用すると、複数の接続を処理する必要がなくなるため、スレッド関数のコードが簡素化されますが、負荷が高くなると大量のリソースが使用される可能性があります。
スレッドごとに複数接続のシナリオでは、コードはもう少し複雑になりますが、通常、最大数のスレッドを常に実行するだけで、スレッドの作成と破棄のオーバーヘッドを最小限に抑えることができます。負荷の高い期間以外は、何もせずにただ座って、接続イベントが与えられるのを待っています。
また、負荷が高い場合でも、各スレッドは遅れることなく 5 つの同時接続を非常に簡単に処理できる可能性があります。つまり、スレッドごとに 1 つの接続というオプションは少し無駄でした。
あなたの更新に基づいて:
つまり、1 つのスレッドで 3 つのソケットとの通信がある場合、1 つのスレッドが 3 つのソケットと通信し、誰も待たずに通信するにはどうすればよいでしょうか?
これを行うには非常に多くの方法があります。まず、通常はすべて呼び出しの背後で抽象化され、おそらくすべての接続を処理し、それらを正しいスレッドにファームアウトするgetNextEvent()
責任があります。
最も低いレベルでは、これは呼び出しのようなもので行うことができます。これはselect
、多くのファイル記述子の 1 つでのアクティビティを待機し、どのファイル記述子が何かを伝えているかに関する情報を返す関数です。
たとえば、現在開いているすべてのソケットのファイル記述子セットを提供し、それを に渡しselect
ます。次に、関心のあるもの (ready-to-read-from など) のみを含む、変更されたセットを返します。
次に、そのセットをクエリして、イベントを対応するスレッドにディスパッチできます。