Source of Additional Thread(s)?

[Smithers]

Does the FileSystemWatcher class, when enabled, spawn a new thread for
itself?

I googled and somehow just found people having random problems with the
FileSystemWatcher class and the MSDN docs. MSDN online didn't clarify (at
least not that I found).

My situation is that I have a Windows Forms app. The application class hosts
a singleton instance of another class. That other class communicates with
the hosting app primarily via events (that it, the singleton, raises). One
of the tasks of the singleton is to spawn a few FileSystemWatcher instances
that monitor a few directories for changes. The FileSystemWatcher events are
handled within the singleton, which, upon certain types of changes turns
around and raises a brand new event which is then handled by the hosting
application - which, in turn, updates UI controls.

When events are raised from the hosted singleton that have nothing to do
with the FileSystemWatcher instances, then the hosting app updates the UI
controls just fine.
But when events are raised from the hosted singleton that are raised from
the FileSystemWatcher event handling methods (within the singleton), then
the hosting application chokes when it goes to update UI controls.
Specifically VS gives me "Cross-thread operation not valid: Control 'xyz'
accessed from a thread other than the thread it was created on."

I believe I do understand the threading issues going on here, and I have
been able to remediate. What I would appreciate a bit of clarification on is
this: Where did the other thread(s) come from? I have not explicitly
launched any additional threads. My suspicion is that the FileSystemWatcher
instances create their own background threads. Is that true? If not, then
what would be a likely source of the additional thread(s) given that I'm not
explicitly creating any.

Thanks!

 

[Guest]

Yes, using the reflector i found the code using the thread, also think
logiclly, the file system watcher proopose is to notify the application on
file changed, this must be in diffrent thread.

Sincerely
Yaron Karni
http://dotnetbible.blogspot.com/

 

[Guest]

Also when lookiong on msdn example you can see that no thread should be
queued for the file notify changed, so it use it internally

 

[Jon Skeet [C# MVP]]

I believe I do understand the threading issues going on here, and I have
been able to remediate. What I would appreciate a bit of clarification on is
this: Where did the other thread(s) come from? I have not explicitly
launched any additional threads. My suspicion is that the FileSystemWatcher
instances create their own background threads. Is that true? If not, then
what would be a likely source of the additional thread(s) given that I'm not
explicitly creating any.

From the docs of FileSystemWatcher.SynchronizingObject:

<quote>
When SynchronizingObject is a null reference (Nothing in Visual Basic),
methods handling the Changed, Created, Deleted, and Renamed events are
called on a thread from the system thread pool. For more information on
system thread pools, see ThreadPool.

When the Changed, Created, Deleted, and Renamed events are handled by a
visual Windows Forms component, such as a Button, accessing the
component through the system thread pool might not work, or may result
in an exception. Avoid this by setting SynchronizingObject to a Windows
Forms component, which causes the methods that handle the Changed,
Created, Deleted, and Renamed events to be called on the same thread on
which the component was created.
</quote>

 

[Smithers]

Well it couldn't be more perfectly clear. I guess I'll be more patient with
the MSDN docs next time. Thanks for the quote.

-S