GNOME Bugzilla – Bug 627285
inotify file monitor hardwired delay
Last modified: 2015-09-09 16:50:58 UTC
the inotify code has a hardwired 1second delay which is causing problems in some places. On the other hand, there is a GFileMonitor::rate-limit property that can be set to smaller values, and the generic file monitor code does its own rate-limiting. I think these two need to know about each other, probably by passing the rate-limit down to the inotify code.
Yes, I agree. That hardwired limit is not nice. However, I've never really studied the inotify backend, so I don't know if there are any particular problems with this.
I noticed the one second delay for the first changed event. In http://git.gnome.org/browse/glib/tree/gio/inotify/inotify-kernel.c#n36, inotify backend will delay one second to process the inotify events from kernel. Why need do this?
Hi Matthias Clasen, Chromium OS has a patch to reduce the delay. It works very well. Could you apply it to glib upstream? Thanks http://git.chromium.org/gitweb/?p=chromiumos-overlay.git;a=blob;f=dev-libs/glib/files/glib-inotify.patch;hb=HEAD
I'd rather have us pass the rate-limit down
Hi Matthias, Sounds good to me. Currently the timing values are hard-coded in inotify-kernel.c. It would be awesome if you could provide a way to control the timing values. BTW, I wrote the patch for Chromium OS that Peng mentioned, as we realized that it took about one second before GFileMonitor notifies file changes, and one second was too slow for us. This may be true for other interactive programs. Peng wrote a test program for this. http://code.google.com/p/chromium-os/issues/detail?id=6375#c20
Hi Matthias, I checked the code of g_file_monitor_emit_event. It will merge some changes to one base on the rate-limit. And other GFileMonitor implementations should simply call g_file_monitor_emit_event to emit the changed signal, and they do not need care about the rate-limit. g_file_monitor_emit_event will handle it. So I think inotify code should emit the change immediately. Right? http://git.gnome.org/browse/glib/tree/gio/gfilemonitor.c#n665
Created attachment 294376 [details] [review] inotify: rewrite inotify-kernel Remove the hardwired 1 second event queue logic from inotify-kernel and replace it with something vastly less complicated. Events are now reported as soon as is possible instead of after a delay. We still must delay IN_MOVED_FROM events in order to look for the matching IN_MOVED_TO events, and since we want to report events in order this means that events behind those events can also be delayed. We limit ourselves, however: - no more than 100 events can be delayed at a time - no event can be delayed by more than 10ms
Attachment 294376 [details] pushed as 779c809 - inotify: rewrite inotify-kernel