Source of Additional Thread(s)?

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

I googled and somehow just found people having random problems with the
FileSystemWatch er 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 FileSystemWatch er instances
that monitor a few directories for changes. The FileSystemWatch er 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 FileSystemWatch er 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 FileSystemWatch er 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 FileSystemWatch er
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!

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

I googled and somehow just found people having random problems with the
FileSystemWatch er 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 FileSystemWatch er instances
that monitor a few directories for changes. The FileSystemWatch er 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 FileSystemWatch er 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 FileSystemWatch er 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 FileSystemWatch er
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!

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 FileSystemWatch er
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.

Smithers <A@B.comwrote :

<snip>

>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
FileSystemWatc her
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 FileSystemWatch er.Synchronizin gObject:

<quote>
When SynchronizingOb ject 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 SynchronizingOb ject 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>

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too