FileSystemWatcher Specific Implementation Check

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

FileSystemWatcher Specific Implementation Check

Rick Tillery
In http://www.mono-project.com/docs/faq/technical/#what-are-the-issues-with-filesystemwatcher, it mentions:

The Mono implementation of FileSystemWatcher has a number of backends, the most optimal one, the one with fewer dependencies is the inotify-backend (available in Mono 1.1.17 and newer versions).

With this backend the kernel provides Mono with updates on any changes to files on the file system but it requires an inotify-enabled kernel, which only newer Linux distributions ship.

In older Linux systems, you must have installed FAM or Gamin (it will work with either one). You might need the -devel packets installed.

For the *BSD family, there’s a Kqueue based implementation that will be used when detected at runtime.

If none of the above work, Mono falls back to polling the directories for changes, which far from optimal.

Is there any way to determine, on a given system, which backend is being used?

Specifically, I have to support a large number of Linux distros and versions going back a number of years, so I need to know that none of them are using polling.

Thanks,
Rick

_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: FileSystemWatcher Specific Implementation Check

Robert Jordan
On 29.08.2017 23:05, Rick Tillery wrote:

> In
> http://www.mono-project.com/docs/faq/technical/#what-are-the-issues-with-filesystemwatcher,
> it mentions:
>
>
>     The Mono implementation of FileSystemWatcher has a number of
>     backends, the most optimal one, the one with fewer dependencies is
>     the inotify-backend (available in Mono 1.1.17 and newer versions).
>
>     With this backend the kernel provides Mono with updates on any
>     changes to files on the file system but it requires an
>     inotify-enabled kernel, which only newer Linux distributions ship.
>
>     In older Linux systems, you must have installed FAM or Gamin (it
>     will work with either one). You might need the -devel packets installed.
>
>     For the *BSD family, there’s a Kqueue based implementation that will
>     be used when detected at runtime.
>
>     If none of the above work, Mono falls back to polling the
>     directories for changes, which far from optimal.
>
> Is there any way to determine, on a given system, which backend is being
> used?
>
> Specifically, I have to support a large number of Linux distros and
> versions going back a number of years, so I need to know that none of
> them are using polling.


You could access the static private field

System.IO.FileSystemWatcher.watcher

via reflection and then check its type:

---
using System;
using System.Reflection;
using System.IO;

class Test {
         public static void Main ()
         {
                 var fsw = new FileSystemWatcher ();
                 var fi = typeof (FileSystemWatcher).GetField
("watcher", BindingFlags.Static | BindingFlags.NonPublic);
                 Console.WriteLine (fi.GetValue (fsw).GetType ());
         }
}
---

The polling watcher's class is "System.IO.DefaultWatcher".

Robert
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list
Reply | Threaded
Open this post in threaded view
|

Re: FileSystemWatcher Specific Implementation Check

Rick Tillery
Excellent! That's exactly what I was looking for.  (Totally forgot about reflection in accessing those protected members.)

I've verified that CentOS 6(.6) uses iNotify, so that's excellent news.  Now if I can figure out why a simple wait for an event seems to be polling in CentOS 6, the FSW approach to keeping the mono cert store automatically sync'd with the system cert store might be baked enough for actual use (know better than to claim fully-baked :-| ).

Thanks!
Rick

On Thu, Aug 31, 2017 at 11:25 AM, Robert Jordan <[hidden email]> wrote:
On 29.08.2017 23:05, Rick Tillery wrote:
In http://www.mono-project.com/docs/faq/technical/#what-are-the-issues-with-filesystemwatcher, it mentions:


    The Mono implementation of FileSystemWatcher has a number of
    backends, the most optimal one, the one with fewer dependencies is
    the inotify-backend (available in Mono 1.1.17 and newer versions).

    With this backend the kernel provides Mono with updates on any
    changes to files on the file system but it requires an
    inotify-enabled kernel, which only newer Linux distributions ship.

    In older Linux systems, you must have installed FAM or Gamin (it
    will work with either one). You might need the -devel packets installed.

    For the *BSD family, there’s a Kqueue based implementation that will
    be used when detected at runtime.

    If none of the above work, Mono falls back to polling the
    directories for changes, which far from optimal.

Is there any way to determine, on a given system, which backend is being used?

Specifically, I have to support a large number of Linux distros and versions going back a number of years, so I need to know that none of them are using polling.


You could access the static private field

System.IO.FileSystemWatcher.watcher

via reflection and then check its type:

---
using System;
using System.Reflection;
using System.IO;

class Test {
        public static void Main ()
        {
                var fsw = new FileSystemWatcher ();
                var fi = typeof (FileSystemWatcher).GetField ("watcher", BindingFlags.Static | BindingFlags.NonPublic);
                Console.WriteLine (fi.GetValue (fsw).GetType ());
        }
}
---

The polling watcher's class is "System.IO.DefaultWatcher".

Robert
_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list


_______________________________________________
Mono-devel-list mailing list
[hidden email]
http://lists.dot.net/mailman/listinfo/mono-devel-list