[Mono-dev] CentOS 6 Wait For Event Polling? [was Re: FileSystemWatcher Specific Implementation Check]

[Rick Tillery]

As a follow-up, I ran the code below using strace on Ubuntu 16.04 and found
the same behavior as I see on CentOS 7 (i.e. waiting for the event blocks).

After checking again on CentOS 6, I find that the gettimeofday() calls DO
end, after being called excatly 3,303 times (same number seen on a couple
of VMs).  Then the futex() blocking call is reached.

This is certainly excessive, but at least it means that once the futex()
call is reached, the process blocks, as expected.

Also, it appears that gettimeofday() does not appear at all on the CentOS 7
or Ubuntu 16.04 traces.

Rick

On Wed, Aug 30, 2017 at 9:24 AM, Rick Tillery <rtillerywork at gmail.com>
wrote:

> I'm still trying to determine which FileSystemWatcher backend is being
> used in different distros and versions. I was trying to see if strace could
> help. But I'm seeing something strange. Using the code below, which just
> blocks, waiting on an event (in the example, one which never triggers), and
> then running with strace, after initialization, I get constant
> getimeofday() calls in CentOS 6:
>
> # strace mono wait.exe
> ...
> gettimeofday({1504101194, 148314}, NULL) = 0
> gettimeofday({1504101194, 148370}, NULL) = 0
> gettimeofday({1504101194, 148480}, NULL) = 0
> gettimeofday({1504101194, 148501}, NULL) = 0
> gettimeofday({1504101194, 148521}, NULL) = 0
> ...
>
>
> In CentOS 7, after initialization, the output pauses, as expected:
>
> # strace mono wait.exe
> ...
> write(1, "Waiting for activity\n", 21Waiting for activity
> )  = 21
> futex(0xb84c6c, FUTEX_WAIT_PRIVATE, 1, NULL[CURSOR HERE]
>
>
> Source code (wait.cs):
>
> using System;
> using System.Threading;
>
> // Compile with "mcs wait.cs"
>
> public class Wait
> {
>     private static ManualResetEvent signal = new ManualResetEvent(false);
>
>     public static int Main()
>     {
>         while (true)
>         {
>             Console.WriteLine("Waiting for activity");
>             signal.WaitOne();
>             Console.WriteLine("Activity detected");
>             signal.Reset();
>         }
>         return 0;
>     }
> }
>
>
> What's going on here? Why is there activity in CentOS 6, while the process
> should be blocked and waiting?
>
> Rick
>
> On Tue, Aug 29, 2017 at 4:05 PM, Rick Tillery <rtillerywork at gmail.com>
> 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.
>>
>> Thanks,
>> Rick
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dot.net/pipermail/mono-devel-list/attachments/20170906/ca4b6837/attachment.html>