GNOME Bugzilla – Bug 487375
gtkrecent apps poll ~/.recently-used.xbel every 5 seconds
Last modified: 2008-11-06 14:20:59 UTC
Please describe the problem: Gnumeric is very nice and friendly saving power while there is no activity and there is no file loaded into the application. neither powertop nor strace shows any sign of activity and this is really nice. But, when you load a file (a simple .xls file on my test) it starts polling the file .recently-used.xbel located in the user's home directory. It uses the function stat64() every 5 seconds causing the CPU to wake up increasing the electricity bill. Steps to reproduce: Start Gnumeric and load a simple file. Actual results: powertop shows that Gnumeric wakes up the CPU every 5 seconds. You can also see the activity with "strace -tt -p <pid-of-gnumeric>". Expected results: There should be no wake ups while the application is inactive no matter if there is a file loaded. Does this happen every time? yes. Other information: This is an up to date Rawhide system (Fedora 8 Test 3). Relevant versions are: gnumeric-1.6.3-12.fc8 gtk2-2.12.0-6.fc8 glib2-2.14.1-1.fc8
Indeed it does. Gnumeric uses gtkrecentmanager, which is part of the GTK toolkit, for handling the recent file list. gtkrecentmanager uses polling. Reassigning bug to GTK.
this is going to be fixed when GTK+ will depend on GVFS and we will have a file monitoring API based on whatever the system provides.
Interesting. This must be for applications which need a live list of recent files. Gnumeric only shows it in the menu. The menu usually isn't up for long periods. Would rebuilding the recent menu when the menu is going to be popped up be too slow? Or too hard to fit into the architecture?
(In reply to comment #3) > Interesting. This must be for applications which need a live list of recent > files. not really: the list is held in memory until the file changes. the GtkRecentManager object used by the recently used resources implementation just stat()s the storage file to check if the mtime did change since the last build sequence. if the mtime did change, the file is re-parsed and the in memory list rebuilt - the GtkRecentManager::changed signal is fired and the various GtkRecentChooser implementations reload their own contents. the GtkRecentChooserMenu that applications commonly uses, for instance, is built when created and renews its contents only when the ::changed signal is emitted. if the GtkRecentManager never emitted the ::changed signal (thus never polled the storage file) the menu would stay exactly the same.
just to make things clear(er): I won't implement a non-portable i-notify based private polling mechanism, or add API to stop and defer the polling that I get to support until the end of times or an API break (whichever comes first), as they would only cripple the code base and allow various degrees of abuse by the developers. I prefer to wait when GLib will have the GIO API and I'll be able to use a GFileMonitor to watch for changes inside GtkRecentManager.
Emmanuele, that's fair enough. I suppose we'll have to wait for Gnome 2.22 for this to be fixed when a new glib release is available. I hope it can be fixed soon because gnome-panel is showing the same problem and normally a user won't shut down the panels to workaround the problem. Cheers.
by the way: starting from gtk+ 2.12.0 the GtkRecentManager uses g_timeout_add_seconds_full() for the timed stat() of the storage file: http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#g-timeout-add-seconds-full (In reply to comment #6) > Emmanuele, that's fair enough. I suppose we'll have to wait for Gnome 2.22 for > this to be fixed when a new glib release is available. as soon as GLib ships GIO, I promise I'll port GtkRecentManager over it. :-)
*** Bug 487357 has been marked as a duplicate of this bug. ***
*** Bug 336671 has been marked as a duplicate of this bug. ***
*** Bug 523608 has been marked as a duplicate of this bug. ***
Created attachment 107990 [details] [review] [PATCH] Use GFileMonitor to monitor the storage file this patch removes the file polling and uses GFileMonitor instead, reducing the code complexity and the wakeups. this is a proof of concept patch, as I cannot test it properly due to the lack of a gvfs-enabled machine. testing from people with GNOME 2.22 is very welcome. configure.in | 2 gtk/gtkrecentmanager.c | 336 +++++++++++++++++-------------------------------- 2 files changed, 120 insertions(+), 218 deletions(-)
Hi, has anyone reviewed this patch? is this going to be included in gtk+ 2.12? or do we have to wait until gtk+ 2.14? Cheers.
it cannot go in gtk+ 2.12, as it depends on gio. it will land in gtk+ trunk, which will become 2.14.
Ok, thanks a lot Emmanuele. I think this is important because it will shave lots of wake ups from several apps in the desktop (gnome-panel, nautilus, abiword, gnumeric, gedit, etc) that are polling every 5 seconds the .recently-used.xbel file each.
I've attached the whole changeset to bug 528035
fixed in trunk. 2008-04-15 Emmanuele Bassi <ebassi@gnome.org> Bug 487375 – gtkrecent apps poll ~/.recently-used.xbel every 5 seconds * gtk/gtkrecentmanager.c: Use GFileMonitor to check for changes in the recently used resources storage file, and drop the timeout-based poll.
Emmanuele, in Fedora 9 I see gnome-panel and clock-applet using inotify_add_watch() in strace. Why is that? I thought they weren't using inotify directly. Would be this a Fedora specific patch? Besides, if they are using inotify why are they still polling every 3 or 4 seconds? Soon I will be updating my machine to rawhide and check again. Cheers.
(In reply to comment #17) > Emmanuele, in Fedora 9 I see gnome-panel and clock-applet using > inotify_add_watch() in strace. > > Why is that? I thought they weren't using inotify directly. Would be this a > Fedora specific patch? yes, Fedora patches gtk+ to do that. > Besides, if they are using inotify why are they still polling every 3 or 4 > seconds? I have no idea whatsoever.
1. We don't have such a patch in F9 anymore. We may have had one in earlier releases 2. You'll see inotify in strace, even if it is used indirectly via GIO 3. Even the inotify-based file monitoring code in GIO falls back to polling for nonexisting files.
This all makes sense but the last point kind of suck. Is there any way to avoid that situation?? what about monitoring the directory instead?? I'll try creating a dummy file to see if the polling go away.
Well, I just posted a comment to bug #522314 because it is talking about the problem explained by Matthias. What do you think about it? do you think the solution explained by Colin Walters is workable?
William, bug #522314 is not relevant to monitoring of ~/.recently-used.xbel because it should always exist. Thanks, John