ファイルのフォルダーを1秒間隔で監視するBackgroundWorkerがあります。ファイルが見つかった場合は、見つかったファイルごとに ReportProgress(0, fileName) を発生させます。
メイン スレッドで、そのイベントをサブスクライブし、各ファイルを処理します。
これは、1 つの見つかったファイル = 1 つの発生したイベント = 1 つの処理されたファイルです。
私の質問は、メイン スレッドが遅い場合のイベントのキューイングについてです。たとえば、「ファイル ウォッチャー」は 1 秒あたり 1000 件のイベントを検出して発生させることができますが、各ファイルを処理するメイン スレッドでは 1 秒かかります。したがって、イベントはキューに入れられます。
.NET でのその種のキューイングに制限はありますか?
ありがとう、バーテック
メインスレッドが最終的にすべてのファイルを処理することはありません。ただし、ある種のGUIがある場合は、別のスレッドで処理を行うことをお勧めします。
BackgroundWorker内部的SynchronizationContextにPost非同期メッセージに使用します。BWを開始するGUIスレッドの場合、専用のWinFormsを使用し、SynchronizationContextメッセージループを使用してそのメインスレッドに進行状況を報告します。
あなたの場合、それはWindowsサービススレッドであり、そのためにはありませんSynchronizationContext。何が起こるかというと、デフォルトSynchronizationContextがインスタンス化されて使用されます。その場合、動作は完全に異なり、ThreadPool非同期メッセージには新しいものが使用されます。その結果、ファイル処理ThreadPoolは、WinFormsのようにメインスレッドではなく、その内部スレッドによって開始される個別のスレッドで実行されます。
大きなキューを正しく処理するThreadPool必要がありますが（ThreadPoolキューサイズの厳しい制限をすぐに見つけることができませんでした-誰か知っていますか？）、このパターンで決定論的な順次ファイル処理を想定できないことを知っておいてください。