Rewrite the glib UI pump.

Rewrite the glib UI pump.  Although the previous pump was correct in terms of test coverage, it was mis-handling the concept of idle work.  This meant we were effectively polling the pump, causing full CPU usage.  The new pump is greatly simplified, and follows the pattern used on Windows.  All tests still pass.

[darin (slow to review), 2008-11-12 18:12:01]

LG

http://codereview.chromium.org/10833/diff/1/2
File base/message_pump_glib.cc (right):

http://codereview.chromium.org/10833/diff/1/2#newcode156
Line 156: // Drain our wakeup pipe, this is a non-blocking read.
Hmm... have you ever seen this have more than 1 byte?  (Might be good to at
least comment that this should ordinarily be a 1 byte read.)

[dsh, 2008-11-12 19:24:42]

This may fix the bug, but is it adaptable to work when GTK widgets run a
recursive main loop on the default context, or is it just going to get
redesigned back to the way it is now with a minor bug fix to get the idle work
done right?

http://codereview.chromium.org/10833/diff/1/2
File base/message_pump_glib.cc (left):

http://codereview.chromium.org/10833/diff/1/2#oldcode180
Line 180: state->should_do_idle_work = true;
It's not really necessary to redesign the whole thing, esp since this is not
correct WRT recursive runs of the main loop via g_main_loop_run (in a GTK
widget).  I think to get it correct it will end up looking a lot like it looks
now.

The current problem is just a bug that could be fixed by adding another state to
RunState that says we tried idle work and can go to sleep on the poll call now.

http://codereview.chromium.org/10833/diff/1/2
File base/message_pump_glib.cc (right):

http://codereview.chromium.org/10833/diff/1/2#newcode160
Line 160: if (state_->delegate->DoWork())
This is much simpler, but the problem is like you said on chat: A GTK widget may
run a loop in the default context (which we are using) which means that this
code will not execute during that time.  This is the reason all the work was
done in the GSource callbacks.