Hi, Igor Stoppa wrote: >>>> How can I work around this? >>> *Don't do unnecessary stuff >>> *Don't poll >>> *Don't busyloop >>> *Check system state (by listening for events, again, never poll) >>> *Keep updates at minimum >>> *Do updates only if your application is visible, otherwise completely >>> stop updating the UI till you become again king of the hill >> Thanks Igor for nice explanation, what about using threads? For n770 >> some time ago people said that using threads (linuxthreads) caused some >> unneeded cpu activity caused by the library itself. Is it still the >> case? >> > Yes, I remember that, but probably Eero has a much better answer already > available, so i'll let him the honour. All Maemo releases including Bora, contain non-NPTL threads implementation which polls. Polling is done by the thread manager which is the second process PID in "top" (third if application uses maemo-launcher). The Maemo version of the thread library is modified to thread less frequently than at the default 2 sec interval. This is not a much of a problem unless you're running *many* threading programs at the same time. (gnome-vfs will create threads when app uses it and this happens also through file selector usage) >> Are there any other similar gotchas present in the SW stack >> (glibc/X/gtk)? X and Gtk are nicely event based and don't poll unnecessarily. However, LibSDL polls several times a second even when the program using SDL is just waiting for events. (both of the games in the device using SDL exit and return back to the Gtk startup screen when screen blanks or game is paused) More information on the SDL issue is here: http://bugzilla.libsdl.org/show_bug.cgi?id=323 > I tend to prefer the thread approach but for coding and reliability > reasons, but that's probably personal taste. One needs native gdb (Scratchbox host-cross-gdb one is not enough) and libc6-dbg package just to get Gdb to list the threads in the process. The problems are not easily reproducable because with threads they are more often triggered with specific timing (and debugging changes that...). With old Valgrind 2.2 one can use Helgrind on x86 which sometimes helps. - Eero
