Ticket #4677 (new defect)

Opened 6 years ago

Last modified 6 years ago

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:
Action Needed: code Verified: no
Deployments affected: Blocked By:
Blocking:

Description

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

Changed 6 years ago by jg

  • priority changed from normal to high

Youch!

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

Changed 6 years ago by jg

  • milestone changed from Never Assigned to Future Release

Changed 6 years ago by gnu

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

Changed 6 years ago by marco

  • keywords 9.1.0? added
  • milestone changed from Future Release to 9.1.0

Changed 6 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.

Changed 6 years ago by marco

  • keywords needs-testing added

Changed 6 years ago by gnu

  • next_action 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.