Treat a delay of under 1 millisecond in MessagePumpDefault as a signal that the corresponding delay…

Treat a delay of under 1 millisecond in MessagePumpDefault as a signal that the corresponding delayed task needs to execute

On Windows for e.g. the lowest resolution we can get on the system clock is 1 ms or 4 ms depending on whether the machine
is powered by AC or battery. The OS default is 15ms. So that effectively means that if a delayed task is waiting to execute
for a delay of under 1 ms would cause the underlying OS WaitForSingleObject call to return immediately effectively spinning
a tight loop with a kernel mode context switch.

Fix is to treat a delay of under 1 ms as a signal that the task is ready to execute for all platforms.

BUG=487724
Committed: https://crrev.com/990d0c7d24a7ef39567875587355637dc9fef122
Cr-Commit-Position: refs/heads/master@{#329997}

[ananta, 2015-05-14 01:15:33]

ananta@chromium.org changed reviewers:
+ cpu@chromium.org

[cpu_(ooo_6.6-7.5), 2015-05-15 00:35:45]

lgtm

[ananta, 2015-05-15 00:36:15]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-05-15 00:36:16]

The CQ bit was unchecked by ananta@chromium.org

[ananta, 2015-05-15 00:36:17]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-05-15 00:37:57]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1137453006/20001

[commit-bot: I haz the power, 2015-05-15 00:42:49]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-05-15 00:43:51]

Patchset 2 (id:??) landed as
https://crrev.com/990d0c7d24a7ef39567875587355637dc9fef122
Cr-Commit-Position: refs/heads/master@{#329997}

[jar (doing other things), 2015-05-15 16:49:01]

jar@chromium.org changed reviewers:
+ jar@chromium.org

[jar (doing other things), 2015-05-15 16:49:02]

drive by commentary (since I'm not really workin' on Chrome these days)

FWIW: This appears to "round down provided delay," rather than "round up," which
was the consensus in the bug discussion.

I have a vague recollection that this will cause some sites to break Chrome
badly, but that was several years ago.  Some JS code (as I recall... perhaps New
York Times was the case in point?) tried to set a delay of 1ms to avoid
overtaxing the CPU.  This class of "rounding down and running now" response
causes such applications to greatly hog CPU resources.

You may be able to find records of this in older bugs, assigned to (or repaired
by) Mike Belshe, when he was working on the system clocks, and high performance
timers.


You should at least be aware of this possible (probable?) result, and watch for
"broken site" bug reports.

[cpu_(ooo_6.6-7.5), 2015-07-22 05:11:50]

for the record, there is this regression. Which might or might not be related.

https://code.google.com/p/chromium/issues/detail?id=509055