BackgroundWorker ReportProgress事件隊列

我有一個BackgroundWorker，以1秒的間隔監視文件夾的文件。如果它找到文件，則會爲每個找到的文件引發ReportProgress（0，fileName）。BackgroundWorker ReportProgress事件隊列

在主線程上，我訂閱了該事件並處理每個文件。

這就是：一個找到的文件=一個引發的事件=一個處理文件

我的問題是關於排隊事件，如果主線程是緩慢的。例如，'文件觀察者'可以每秒查找並提高1000個事件，但在處理每個文件的主線程上需要1秒。所以事件排隊。

這種排隊在.NET中有沒有限制？

感謝，鮑爾泰克

2012-07-16 bodziec

您可以使用['FileSystemWatcher'類]（http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx）而不是後臺工作者？ – 2012-07-16 07:49:20

當頻繁/重大更改發生時''FileSystemWatcher''不可靠。改變它的內部緩衝區可能會有幫助，但是它也有很大的限制。 – 2012-07-16 10:57:12

無主線程將最終過程中的所有文件。但是，如果您有某種GUI，我建議您在單獨的線程上進行處理。

來源

2012-07-16 07:49:31 James

這是一個Windows服務，所以這應該沒問題。我只是想知道，如果有什麼不會錯過，但正如你所說，這看起來確實。謝謝 – bodziec 2012-07-16 08:02:39

@bodziec所有的事件都應該得到處理，除非在處理過程中發生異常。但是，有幾種方法可以處理這種情況。 – James 2012-07-16 08:33:07

BackgroundWorker內部使用SynchronizationContext到Post異步消息。如果它是啓動BW的GUI線程，它將使用專門的WinForms SynchronizationContext並使用消息循環向該主線程報告進度。

在你的情況，這是一個Windows服務線程，因此沒有SynchronizationContext。會發生什麼情況是默認SynchronizationContext被實例化和使用。行爲則完全不同，並且新的ThreadPool用於異步消息。因此，您的文件處理將發生在由內部ThreadPool啓動的單獨線程中，與主線程相反，因爲它在WinForms中。

雖然ThreadPool應該能夠正確處理大隊列（不能立即在ThreadPool隊列大小上找到任何硬限制 - 任何人都知道？），但要知道在這種模式下您不能假定確定性的順序文件處理。

來源

2012-07-16 09:52:02

據我所知，ThreadPool隊列沒有硬性限制。唯一的限制是機器有足夠的資源來處理負載。 – James 2012-07-16 15:14:53

BackgroundWorker ReportProgress事件隊列

回答

相關問題