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事件队列

回答

相关问题