diff options
author | kjellander <kjellander@chromium.org> | 2015-06-10 00:53:58 -0700 |
---|---|---|
committer | Commit bot <commit-bot@chromium.org> | 2015-06-10 07:54:25 +0000 |
commit | e799035ef225f9238d5aa7bea125d6d0289db3cd (patch) | |
tree | 1b48471a91675dec344ac565c3bfc2ca189131a6 /courgette | |
parent | 6cddaa991266cd12f37625fd390e0d36a93e49c3 (diff) | |
download | chromium_src-e799035ef225f9238d5aa7bea125d6d0289db3cd.zip chromium_src-e799035ef225f9238d5aa7bea125d6d0289db3cd.tar.gz chromium_src-e799035ef225f9238d5aa7bea125d6d0289db3cd.tar.bz2 |
Revert of Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message. (patchset #13 id:240001 of https://codereview.chromium.org/1156503005/)
Reason for revert:
I suspect this CL breaks Windows 8 content_unittests, as it's listed both in
https://build.chromium.org/p/chromium.fyi/builders/Win8%20Tests%20%281%29/builds/8675 and our WebRTC-specific waterfall: https://build.chromium.org/p/chromium.webrtc/builders/Win8%20Tester/builds/14164
I'll try to reland if it turns out not to solve the breakage.
Original issue's description:
> Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.
>
> Currently the MessagePumpForUI class peeks Windows messages when we receive the kMsgHaveWork message in
> our main message loop and in nested modal loops. This is because the posted message starves the message loop
> of input and other lower priority messages. While this is ok for the main message loop our peeking and dispatching
> messages in nested loops is wrong and violates the silent contract where in the nested loop should be the one peeking
> and dispatching messages.
>
> To fix this the approach we are taking is to create a worker thread which uses a waitable timer of 3 ms which posts
> the kMsgHaveWork message to the main loop when the timer fires. As a result we can safely delete all the code
> in the MessagePumpForUI::ScheduleWork function and simplify the ProcessPumpReplacementMessage function.
>
> The MessagePumpForUI::ScheduleWork function now checks the delay for the task at the head of the queue
> If it is 0 then we post the message right away as it is a regular task. Added functions (GetNewlyAddedTaskDelay) to the MessagePump::Delegate class and the IncomingTaskQueue for this.
>
> The other change here is to change the GPU process to use the IO message pump by default and use the UI pump only
> if we are using opengl. Reason being this patch causes a delay in processing tasks due to the worker thread which
> causes tests like webgl_conformance to fail. We will continue working on addressing this over the coming days.
>
> BUG=492837
> R=cpu
>
> Committed: https://crrev.com/b8e126c8b532b1327f38afe2bdf59aa5ff933971
> Cr-Commit-Position: refs/heads/master@{#333572}
TBR=cpu@chromium.org,jar@chromium.org,kbr@chromium.org,geofflang@chromium.org,scottmg@chromium.org,ananta@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=492837
Review URL: https://codereview.chromium.org/1163423006
Cr-Commit-Position: refs/heads/master@{#333700}
Diffstat (limited to 'courgette')
0 files changed, 0 insertions, 0 deletions