GNOME Bugzilla – Bug 739322
File notifications are delayed
Last modified: 2015-09-13 16:05:19 UTC
Created attachment 289554 [details] test case Hi. This is a continuation of the bug reported in https://bugzilla.gnome.org/show_bug.cgi?id=739274 That bug had a test case where file notifications from glib would not be reported correctly. With the change suggested in that bug, I now see notifications, but they generally come in 1 second after the actual file system activity happened. On my system glib is using inotify internally, so it knows about any activity immediately (ik_read_callback() is called). However the user of glib is not told about this until later. It would be much nicer if glib reported activity as soon as it itself was notified. I'm attaching a simple test file to show the issue. It sets up a monitor on /tmp/dat, and prints something to the console when a modification is detected. This modification comes about 1 second after it should. Thanks
This is caused by: #define PROCESS_EVENTS_TIME 1000 /* 1000 milliseconds (1 hz) */ in inotify-kernel.c. I'm not sure what purpose this delay serves though.
We use this to try to coalesce events in order to fold multiple notifications on a single file into a single signal delivery and also in order to match the two events that correspond to a move into a single signal. I suspect we would not want to abandon either of these unless we can come up with a way to do it without the wait.
glib is a library that applications use to get their data, and I would say that such logic (consolidating multiple notifications into a single event by waiting) really belongs on the application side. The current implementation misrepresents reality to the application in a way that the application may not want. I would welcome abandoning at least the first one. The behavior could be selectable at runtime, if we really want.
(In reply to comment #3) > glib is a library that applications use to get their data, and I would say that > such logic (consolidating multiple notifications into a single event by > waiting) really belongs on the application side. The current implementation > misrepresents reality to the application in a way that the application may not > want. I would welcome abandoning at least the first one. The behavior could be > selectable at runtime, if we really want. I don't agree. Above all else, GLib is an abstraction. People using these APIs may be running on other platforms with other notification frameworks. They could be on NFS and using fam. They could be using a notification framework rolled into a network protocol. If you depend on the semantics of inotify directly then it is possible for you to use inotify directly. If not, it's reasonable to see GLib as an abstraction that may or may not faithfully adhere to details of behaviour of any particular implementation. From a purely "what is the best interface" guideline I agree that reporting sooner rather than later is better, but if we have good reasons for delaying (which I expect we do) then I'd take them over a hard-and-fast rule about faithfully representing the underlying mechanism.
see bug 627285 for what should be done here
> > glib is a library that applications use to get their data, and I would say that > > such logic (consolidating multiple notifications into a single event by > > waiting) really belongs on the application side. > > I don't agree. Above all else, GLib is an abstraction. People using these > APIs may be running on other platforms with other notification frameworks. > They could be on NFS and using fam. They could be using a notification > framework rolled into a network protocol. Certainly that's all true. > If you depend on the semantics of inotify directly then it is possible for you > to use inotify directly. If not, it's reasonable to see GLib as an abstraction > that may or may not faithfully adhere to details of behaviour of any particular > implementation. > > From a purely "what is the best interface" guideline I agree that reporting > sooner rather than later is better, but if we have good reasons for delaying > (which I expect we do) then I'd take them over a hard-and-fast rule about > faithfully representing the underlying mechanism. An arbitrary 1-second delay is hardly "semantics". I'm arguing that we try to faithfully describe /reality/ rather some quirk of inotify. And I do agree that limiting logic could be useful, and an application might want it, but that decision should be left to the application.
We don't have an arbitrary 1-second delay anymore.