"Stampede" wrote:
Hi,
I want to use the FileSystemWatcher in a Windows Service. I read an article,
where the author created the FileSystemWatcher object in a seperate thread
and when the event is fired, he started a working thread for processing the
file, created a new FileSystemWatcher (as he said for real time processing),
and then called the join method for the first thread.
I can't really see the sence in this. Aren't the events of the
FileSystemWatcher created in seperate threads? (As it works with asynchronus
Sockets, I think)
Because if so, then the seperate thread for the FileSystemWatcher and the
creation of a new one for the new files would be complete nonsense.
I hope someone can clear this. I need to know how FileSystemWatcher works
and if it uses threads or not.
greetings
Florian
Hi Florian,
All events triggered by a FileSystemWatcher instance, are called on a thread
pool thread.
If your response to the event is a lengthy operation, you may consider
handling the event further on a seperate thread because the following
registered handlers aren't called until yours completes.
Although I don't know for sure, it may even be that other events triggered
by one file operation aren't executed until all previous events have
completed (one file operation may trigger several FileSystemWatcher events).
Also, it is possible that a FileSystemWatcher's event buffer overflows (the
buffer does not grow). So if your handling would keep other events from being
fired then this could result in buffer overflow so events would be lost.
So basically, if you don't do a lot when handling such an event, that's
fine. If however handling such an event is a lenghty operation, you may want
to handle the event on a seperate (worker) thread.
Hope this helps,
--
Tom Tempelaere.
