GNOME Bugzilla – Bug 688246
add infrastructure to detect when the main loop blocks for a significant time
Last modified: 2012-11-13 13:51:21 UTC
To diagnose and improve on the Shell blocking its compositor for I/O (Bug #687362), I've added infrastructure to GLib to detect when the main loop goes for more than n µs in the same dispatch() call. I've tried various versions of the branch with a different setup: * --enable-block-detection=USEC configure option (I've been using 20000 µs, i.e. 20 ms, as my arbitrary threshold for reporting, but Shell sometimes blocks for 100 ms or more) * either act on the default main context (lower-overhead), or every main context * if dispatch() blocks for more than USEC µs, issue a diagnostic (either a g_warning(), or an access()-based profiling point as used for <http://people.gnome.org/~federico/news-2006-03.html#timeline-tools> which can be picked up with strace) * optionally also issue a diagnostic if check() or prepare() blocks for more than USEC/10 µs (currently hard-coded - I hold these functions to a higher standard because they're "meant to be fast"); this is rarely seen in practice, at least in Shell * optionally record the (glibc-specific) backtrace when a GSource is added, and format it for the diagnostic if that source takes too long, to aid in identifying which module should be blamed (e.g. when the callback that took too long was g_idle_dispatch, which is quite common) Would there be interest in merging any of this functionality?
*** This bug has been marked as a duplicate of bug 588139 ***