0

Lets say a file is created at time 00:00:00 (hr:mm:ss) and another file is created 5 seconds later (00:00:05) and another file is created in 5 minutes (00:05:00).

If I have a filesystemwatcher that is watching for a "file created" event... and then adds this file path to a queue... and then does something with it that takes 30 seconds and then checks the queue again. Will the second file path be waiting in this queue (the one that happened 5 seconds later)? Or will it skip it because it happened in the middle of 30 seconds it was doing logic? I feel like this is a dumb question because I always thought/assumed the filesystemwatcher "kept watching" and never missed anything even if the program was still processing the last file. But it just occurred to me that it couldn't really do that unless the program was multi-threaded (2 threads). One thread for the watcher to constantly watch and a second thread to do stuff that takes 30 seconds. Or is it automatically designed to do this hidden away in the code behind and I just don't need to worry about it?

XCELLGUY
  • 179
  • 2
  • 12
  • Why would the FSW's event handler check the queue? `unless the program was multi-threaded` that's easy to do with .NET. There are several ways to implement asynchronous pub/sub and perhaps the simplest is to use an `ActionBlock` to receive and process events in its own task/thread – Panagiotis Kanavos Oct 02 '20 at 17:14
  • Have you configured the [`SynchronizingObject`](https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher.synchronizingobject) property of the `FileSystemWatcher`? If not, then the event handler will run on `ThreadPool` threads, without any overlapping restriction. – Theodor Zoulias Oct 02 '20 at 17:31
  • I am pretty much a novice at this stuff... I haven't really done anything yet. I was trying to think through how I would go about what I am wanting to do before I did anything. – XCELLGUY Oct 02 '20 at 17:35
  • [Asynchronous programming](https://learn.microsoft.com/en-us/dotnet/csharp/async) – aepot Oct 02 '20 at 18:24
  • This would be pretty simple to test. Use `Thread.Sleep()` as the work, then drop a file and see if it gets caught during the sleep period... – Idle_Mind Oct 02 '20 at 18:30
  • My previous comment about overlapping events was probably incorrect. From [what I read now](https://stackoverflow.com/questions/45586630/is-there-a-way-to-know-how-much-buffer-is-left-for-filesystemwatcher), a single thread invokes all event handlers for the currently buffered changes, and if the handlers are doing anything time-consuming then you may lose notifications of future changes. This is also reflected in the [documentation](https://learn.microsoft.com/en-us/dotnet/api/system.io.filesystemwatcher#events-and-buffer-sizes): *Keep your event handling code as short as possible.* – Theodor Zoulias Oct 02 '20 at 18:39

0 Answers0