Opened 9 years ago

Last modified 9 years ago

#4677 new defect

Sugar apps' pygtk main loop polls 10 times a second, always; rest of Sugar polls too

Reported by: gnu Owned by: marco
Priority: high Milestone: 9.1.0-cancelled
Component: sugar Version: 1.0-software-build-623
Keywords: power 9.1.0? needs-testing Cc:
Blocked By: Blocking:
Deployments affected: Action Needed: code
Verified: no


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)
1063 {
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.
1071 */
1072 #ifndef PLATFORM_WIN32
1073 if (pyg_threads_enabled)
1074 #endif
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:1 Changed 9 years ago by jg

  • Priority changed from normal to high


Could you file separate bugs for each component you find broken, and we'll use this as a tracker bug for them all?

comment:2 Changed 9 years ago by jg

  • Milestone changed from Never Assigned to Future Release

comment:3 Changed 9 years ago by gnu

Filed #4678, #4679, #4680 as separate bugs.

comment:4 Changed 9 years ago by marco

  • Keywords 9.1.0? added
  • Milestone changed from Future Release to 9.1.0

comment:5 Changed 9 years ago by tomeu

F-9 has included a patch for this in python, and latest pygobject and pygtk should have a fix as well. We should check again in OLPC-3.

comment:6 Changed 9 years ago by marco

  • Keywords needs-testing added

comment:7 Changed 9 years ago by gnu

  • Action Needed set to code

Tested it today in joyride-2263. Results reported in #4680, summary: It's not fixed yet, requires fixes in at least Python (F9 got the wrong patch) and PyGTK (their early fixes weren't right either). This will not make 8.2.0. Polling is down to 1/sec not 10/sec tho.

Note: See TracTickets for help on using tickets.