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?