そのため、イベントが発生し、それを複数のサブスクライブされた「リスナー」に「ブロードキャスト」する必要がある状況があります。
私の現在の設計は、各サブスクライバーのループであり、シリアルに動作し、各「レシーバー」に順番に通知します。
ただし、一部の負荷/ストレステストでは、受信者のリストの＃15が通知を受信するまでに長時間待機する可能性があるため、自分が好きな以上にキューに入れることができることがわかりました。
受信者のリストに多かれ少なかれ同時に通知を受信させる方法を提供したいと思います。
ThreadPoolが出ています。その理由については私自身の理由があります。
私の懸念はパフォーマンスです。これが私が考えていることです...
A.イベントが発生するたびに、レシーバー固有の通知を行うために、レシーバーごとに1つのスレッドが作成されます。通知が完了すると、スレッドは終了します。
----または----
B.イベントが最初に発生すると、レシーバーごとにスレッドが作成されますが、これは「無限」のスレッドであり（ループが存続します）、通知の詳細がそれぞれにマーシャリングされます。これらのスレッドのうち、新しいデータを処理します。
したがって、問題は次のとおりです。新しいスレッドを作成する、または既存のスレッドにデータをマーシャリングするのに費用がかかるのでしょうか。それとも同じくらい費用がかかるのであれば、なぜ一方を選択するのでしょうか。