FileSystemWatcher Events - Threads or not?

[Stampede]

Hi,
I want to use the FileSystemWatch er in a Windows Service. I read an article,
where the author created the FileSystemWatch er object in a seperate thread
and when the event is fired, he started a working thread for processing the
file, created a new FileSystemWatch er (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
FileSystemWatch er created in seperate threads? (As it works with asynchronus
Sockets, I think)

Because if so, then the seperate thread for the FileSystemWatch er 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 FileSystemWatch er works
and if it uses threads or not.

greetings

Florian

[TT (Tom Tempelaere)]

RE: FileSystemWatch er Events - Threads or not?

"Stampede" wrote:
[color=blue]
> Hi,
> I want to use the FileSystemWatch er in a Windows Service. I read an article,
> where the author created the FileSystemWatch er object in a seperate thread
> and when the event is fired, he started a working thread for processing the
> file, created a new FileSystemWatch er (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
> FileSystemWatch er created in seperate threads? (As it works with asynchronus
> Sockets, I think)
>
> Because if so, then the seperate thread for the FileSystemWatch er 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 FileSystemWatch er works
> and if it uses threads or not.
>
> greetings
> Florian[/color]

Hi Florian,

All events triggered by a FileSystemWatch er 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 FileSystemWatch er events).

Also, it is possible that a FileSystemWatch er'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.

[TT (Tom Tempelaere)]

RE: FileSystemWatch er Events - Threads or not?

Hi again,

Hints and tips here:

http://www.knowdotnet.com/articles/fwrecovery.html

http://weblogs.asp.net/ashben/archive/2003/10/14/31773.aspx

Or search the net for more

Cheers,
--
Tom Tempelaere.


"Stampede" wrote:
[color=blue]
> Hi,
> I want to use the FileSystemWatch er in a Windows Service. I read an article,
> where the author created the FileSystemWatch er object in a seperate thread
> and when the event is fired, he started a working thread for processing the
> file, created a new FileSystemWatch er (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
> FileSystemWatch er created in seperate threads? (As it works with asynchronus
> Sockets, I think)
>
> Because if so, then the seperate thread for the FileSystemWatch er 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 FileSystemWatch er works
> and if it uses threads or not.
>
> greetings
>
> Florian[/color]

[Stampede]

RE: FileSystemWatch er Events - Threads or not?

Thanks a lot for that answer, I just thought that noone might really know how
this class does its work!

greetings

Florian

"TT (Tom Tempelaere)" wrote:
[color=blue]
> "Stampede" wrote:
>[color=green]
> > Hi,
> > I want to use the FileSystemWatch er in a Windows Service. I read an article,
> > where the author created the FileSystemWatch er object in a seperate thread
> > and when the event is fired, he started a working thread for processing the
> > file, created a new FileSystemWatch er (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
> > FileSystemWatch er created in seperate threads? (As it works with asynchronus
> > Sockets, I think)
> >
> > Because if so, then the seperate thread for the FileSystemWatch er 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 FileSystemWatch er works
> > and if it uses threads or not.
> >
> > greetings
> > Florian[/color]
>
> Hi Florian,
>
> All events triggered by a FileSystemWatch er 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 FileSystemWatch er events).
>
> Also, it is possible that a FileSystemWatch er'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.
>[/color]