Change the strategy used to attempt nesting-deferred work to account equally...

Change the strategy used to attempt nesting-deferred work to account equally
well for nested run loops under our own control (those started by Run) and
those beyond our control (native event loops).

Previously, upon any exit from a nested native loop, we would schedule
nesting-deferred work for processing.  However, some nested native loops do
not execute in a single loop; rather, they start and stop the CFRunLoop
rapidly.  In such cases, each exit from the CFRunLoop would cause
nesting-deferred work to be scheduled, and on each new entry to the CFRunLoop,
we would attempt to process it.  This rapid-fire action meant that we'd never
sleep.  Nested loops managed by Run were exempt from these problems since
r28811, because we could defer scheduling nesting-deferred work until
returning to Run.

The new strategy is to detect whether any nested loops (native or managed by
Run) had run before the run loop goes to sleep or exits.  If any nested loops
did run, nesting-deferred work is scheduled for processing.

BUG=24968
TEST=1. Test case from bug 24968, printing: open any page, press command-P,
        leave the dialog up, and check Chrome's CPU usage.  No Chrome process
        should be monopolizing any CPU.  This tests nested native run loops.
     2. Test case from bug 24337, JS alerts: open Gmail, start composing a new
        message in a new window, address it to yourself, move focus to the
        subject field, click the Discard button, and click "OK" at the alert.
        The alert and composition window should close.
     3. Test case from bug 24383, JS alerts: no Chrome processes should use
        100% CPU after visiting javascript:alert("hi").  The JS alert cases
        test nested run loops managed by Run.
     4. Test case from bug 13468 comment 5, autocomplete: autocomplete should
        still work after using "Back" from a contextual menu.  This tests
        that nesting-deferred work is processed after leaving a nested run
        loop.
     5. First run UI test case (no bug).  Remove or move aside the profile
        directory (~/Library/Application Support/Chromium or
        ~/Library/Application Support/Google/Chrome) and launch the
        application.  There should be first-run UI and it should be usable.
        Upon clicking "Start (application)", the application should start and
        be usable as normal.  This tests delegateless run loops and
        delegateless work redispatch.
     6. base_unittests --gtest_filter='MessageLoopTest.*'

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=29749

[Mark Mentovai, 2009-10-21 22:36:21]

Stuart, with the aid of the change description, reviewing this shouldn't be as
much of a chore as you may have feared.

The "delegateless" check is not related to this fix, but it's not worth doing a
separate change for that.

[stuartmorgan, 2009-10-21 22:46:10]

LGTM

[Mark Mentovai, 2009-10-21 23:22:56]

New version.  Probably even better.

I've changed the strategy slightly this time to call
MaybeScheduleNestingDeferredWork from the run loop observers when the loop is
about to go to sleep or exit.  This will catch the weird case that might occur
if we schedule events while a native loop is running from a Cocoay callback
instead of something that happens on RunWork, RunDelayedWork, or RunIdleWork.

We need to do both the pre-wait observer and the exit observer because some run
loops don't go to sleep, they're just cranked once and then exit.

[stuartmorgan, 2009-10-21 23:35:17]

LGTM

http://codereview.chromium.org/300044/diff/5/7
File base/message_pump_mac.mm (right):

http://codereview.chromium.org/300044/diff/5/7#newcode385
Line 385: self->MaybeScheduleNestingDeferredWork();
Since it might seem counter-intuitive to have this before the decrement (after
all, it was written the other way the first time), maybe put a brief comment
saying that want to process work on the next run of the outer loop, rather than
the end of the inner loop?