Fix timer interval race condition
The feature flag that I added to control whether the Windows timer interval on DC power should be 4 ms or 8 ms had a race condition in that we might query the feature flag before the feature-flag system was configured. This change fixes that by adding the ReadMinTimerIntervalLowResMs function which is called after the feature system is initialized. While working on this I realized that ActivateHighResolutionTimer and EnableHighResolutionTimer were extremely subtle so I simplified them. When calling timeBeginPeriod you *must* eventually call timeEndPeriod to undo your request, and you must call it with exactly the same value. With the raised timer frequency now having three possible values (1, 4, or 8 ms) the logic was getting far too messy so I now do the simpler task of just recording the value passed to timeBeginPeriod and using it in timeEndPeriod. This is more obviously correct. The new rule is that timeBeginPeriod and timeEndPeriod should always be called with g_last_interval_requested as the parameter. I also tidied up and expanded on some comments - I always get confused by the purpose and semantics of ActivateHighResolutionTimer and EnableHighResolutionTimer. I tested with --disable-highres-timer, with and without --enable-features=SlowDCTimerInterruptsWin, using trace_timer_intervals.bat to confirm that all Chrome processes were lower the timer interrupt setting to 4 ms or 8 ms as requested. Bug: 1033108, 927165 Change-Id: I69b9253b456d7e3273ea1823a61c20926b0a4510 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1965846Reviewed-by:Ken Rockot <rockot@google.com> Reviewed-by:
Yuri Wiitala <miu@chromium.org> Reviewed-by:
Wez <wez@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/master@{#726561}
Showing
Please register or sign in to comment