CODEWITHSUNDEEP
c#.netbackgroundworker
bodziec
bodziec

Reputation: 594

BackgroundWorker ReportProgress event queue

I have a BackgroundWorker that monitors a folder for files in 1sec interval. If it finds file(s) then it raises the ReportProgress(0, fileName) for every found file.

On the main thread I subscribe to that event and handle each file.

This is: one found file = one raised event = one handled file

My question is about queuing events if the main thread is slow. For example the 'file watcher' can find and raise 1000 events per second but on the main thread handling each file takes 1 sec. So events are queued.

Is there any limit for that kind of queuing in .NET ?

Thanks, Bartek

Upvotes: 2

Views: 581

Answers (2)

Jacek Gorgoń
Jacek Gorgoń

Reputation: 3214

BackgroundWorker internally uses SynchronizationContext to Post asynchronous messages. If it was GUI thread starting the BW, it'd use a specialized WinForms SynchronizationContext and report progress to that main thread using message loop.

In your case, it's a windows service thread and as such has no SynchronizationContext. What happens is the default SynchronizationContext is instantiated and used. The behavior is then completely different and a new ThreadPool is used for asynchronous messages. As a result, your file processing will take place in separate threads started by that internal ThreadPool, as opposed to main thread as it is in WinForms.

While ThreadPool should correctly handle large queues (could not immediately find any hard limits on ThreadPool queue size - anyone know?), do know that you can not assume deterministic sequential file processing in this pattern.

Upvotes: 0

James
James

Reputation: 82096

No the main thread will eventually process all the files. However, if you have some sort of GUI I would recommend you do the processing on a separate thread.

Upvotes: 1

Related Questions