Description of problem: yum-updatesd keeps waking up 10 times per second while it's idle. This is obviously not a good idea, it eats compute and battery power for absolutely no reason. To check this, just do strace -tt -p <pid of python that runs the updated> I've not yet been able to find where this is coming from but FC6 really shouldn't ship with this one
static gboolean pyg_signal_watch_prepare(GSource *source, int *timeout) { /* Python only invokes signal handlers from the main thread, * so if a thread other than the main thread receives the signal * from the kernel, PyErr_CheckSignals() from that thread will * do nothing. So, we need to time out and check for signals * regularily too. * Also, on Windows g_poll() won't be interrupted by a signal * (AFAIK), so we need the timeout there too. */ #ifndef PLATFORM_WIN32 if (pyg_threads_enabled) #endif *timeout = 100; return FALSE; }
Right, it happens that when thread awareness is enabled in pygobject, the 100ms timeout is used. This used to be upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=154779
afaik the kernel only sends signals to threads that don't have them blocked. If python doesn't want anyone but the main thread to get signals, it should just block signals on all but the main thread and then by nature, all signals will go to the main thread....
Well, I guess we have to tell that to the Python developers, then... :|
pygobject 2.12.2 raises the timeout to 1000msec (1s): http://mail.python.org/pipermail/python-announce-list/2006-October/005285.html which is lower frequency than many other system services (e.g. avahi-daemon) and would probably make yum-updatesd insignificant in terms of battery/CPU use.
Seems like a good candidate for a quick post FC6 update.
Packaged up gobject-2.12.2-1.fc6. I'll close this bug once it's available in Fedora Updates.
Package pushed to Fedora Updates. Closing this bug.