Comment #7 on issue 24968 by [email protected]: High CPU Usage
while "Print"
http://code.google.com/p/chromium/issues/detail?id=24968
The following revision refers to this bug:
http://src.chromium.org/viewvc/chrome?view=rev&revision=29749
------------------------------------------------------------------------
r29749 | [email protected] | 2009-10-21 18:47:49 -0700 (Wed, 21 Oct 2009) |
42 lines
Changed paths:
M
http://src.chromium.org/viewvc/chrome/trunk/src/base/message_pump_mac.h?r1=29749&r2=29748
M
http://src.chromium.org/viewvc/chrome/trunk/src/base/message_pump_mac.mm?r1=29749&r2=29748
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.*'
Review URL: http://codereview.chromium.org/300044
------------------------------------------------------------------------
--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings
--~--~---------~--~----~------------~-------~--~----~
Automated mail from issue updates at http://crbug.com/
Subscription options: http://groups.google.com/group/chromium-bugs
-~----------~----~----~----~------~----~------~--~---
