Sugar apps' pygtk main loop polls 10 times a second, always; rest of Sugar polls too
|Reported by:||gnu||Owned by:||marco|
|Keywords:||power 9.1.0? needs-testing||Cc:|
|Deployments affected:||Action Needed:||code|
I noticed that the simcity Python helper process was doing tons of system calls -- lots of poll() calls with timeouts of 100ms. You can see this by running the strace command on any Python sugar application, such as the Journal's sugar-activity-factory,
The sugar_shell_service polls every 1 second (1000 ms); I don't know by what mechanism.
The sugar_datastore_service sets this timeout to 0 (it polls constantly), but it then uses select() to delay for 2.5ms. So it polls about 400 times a second.
So I debugged the SimCity one. The timeout is used in the poll() call in g_main_loop_run() in glib2, and is set by this code in pygtk_main_watch_prepare in pygtk2's gtk.override:
1058 /* This code (pygtk main watch) was copied with minor changes from
1059 * pygobject/gobject/pygmainloop.c */
1060 static gboolean
1061 pygtk_main_watch_prepare(GSource *source,
1062 int *timeout)
1064 /* Python only invokes signal handlers from the main thread,
1065 * so if a thread other than the main thread receives the signal
1066 * from the kernel, !PyErr_CheckSignals() from that thread will
1067 * do nothing. So, we need to time out and check for signals
1068 * regularily too.
1069 * Also, on Windows g_poll() won't be interrupted by a signal
1070 * (AFAIK), so we need the timeout there too.
1072 #ifndef PLATFORM_WIN32
1073 if (pyg_threads_enabled)
1075 *timeout = 100;
Clearly, this code should not be waking up every 10th of a second to "check for signals" -- neither on the OLPC, nor on millions of other machines running Python GTK applications. But I don't know enough about this code to suggest a fix.
Change History (7)
comment:4 Changed 9 years ago by marco
- Keywords 9.1.0? added
- Milestone changed from Future Release to 9.1.0