Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.

Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message.
Relanding this patch with fixes for the performance issues reported with the worker thread hogging the CPU continuosly. (https://codereview.chromium.org/1181263008/)

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.

To prevent the UI worker thread from continuously posting the timer we use a flag to control the same.
The flag ensures that the worker thread posts the timer once for each iteration.

This patch also contains a fix for the crash reported in bug 501602 which occurs due to the GetNewlyAddedTaskDelay
function being called from the WndProc which does not have the incoming queue lock. Fix is to move some of the
logic in the ScheduleWork function to the newly added ScheduleWorkHelper function.

BUG=492837, 501602
TBR=cpu

Committed: https://crrev.com/4d5496cde5b81436954e31a9fe82e35ccfe5de49
Cr-Commit-Position: refs/heads/master@{#335475}

[ananta, 2015-06-18 18:59:47]

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

[scottmg, 2015-06-18 20:40:44]

scottmg@chromium.org changed reviewers:
+ brucedawson@chromium.org

[scottmg, 2015-06-18 20:40:45]

The added flag looks ok to me. Maybe +Bruce can confirm that this doesn't cause
tons of wakeups now?

[brucedawson1, 2015-06-18 21:12:19]

I'm at the airport now but I will definitely check it out tomorrow. It looks
like a plausible fix. Thanks.

[cpu_(ooo_6.6-7.5), 2015-06-19 21:35:05]

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

[cpu_(ooo_6.6-7.5), 2015-06-19 21:35:37]

adding kbr unless somehow we can get jbauman to take a peek, but seems OOO.

[ananta, 2015-06-19 22:20:06]

Applied brucedawson's comments from the previous patch
https://codereview.chromium.org/1189133003 to this patch

[Ken Russell (switch to Gerrit), 2015-06-19 22:28:23]

content/gpu change LGTM

+jmadill and geofflang as FYI

geofflang has done more experimentation and we are optimistic that we can get
rid of the UI type MessageLoop on Windows even for the OpenGL case, but let's
leave it as is for now. (Hopefully this won't affect the chromium.gpu.fyi bots
too badly)

[scottmg, 2015-06-19 22:46:02]

lgtm

[ananta, 2015-06-20 23:12:13]

The CQ bit was checked by ananta@chromium.org

[ananta, 2015-06-20 23:12:14]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org
Link to the patchset: https://codereview.chromium.org/1194673004/#ps20001
(title: "Fix the crash reported in bug 501602. The patch description has been
updated with comments about th…")

[commit-bot: I haz the power, 2015-06-20 23:12:25]

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

[commit-bot: I haz the power, 2015-06-21 01:38:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-21 01:38:31]

Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)

[ananta, 2015-06-21 04:25:48]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-06-21 04:25:50]

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

[commit-bot: I haz the power, 2015-06-21 06:23:44]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-06-21 06:23:46]

Try jobs failed on following builders:
  ios_dbg_simulator_ninja on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios_dbg_simulator...)

[ananta, 2015-06-22 04:37:16]

The CQ bit was checked by ananta@chromium.org

[commit-bot: I haz the power, 2015-06-22 04:37:26]

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

[commit-bot: I haz the power, 2015-06-22 06:10:51]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-06-22 06:11:41]

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

[jbauman, 2015-07-01 21:16:08]

A revert of this CL (patchset #2 id:20001) has been created in
https://codereview.chromium.org/1222013004/ by jbauman@chromium.org.

The reason for reverting is: Causes one 1 task to run per 3 ms when in a nested
modal loop, which causes resize to lag behind.

BUG=505612.

[dcheng, 2015-07-01 22:50:46]

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

[dcheng, 2015-07-01 22:50:47]

https://codereview.chromium.org/1194673004/diff/20001/base/message_loop/messa...
File base/message_loop/message_pump_win.cc (right):

https://codereview.chromium.org/1194673004/diff/20001/base/message_loop/messa...
base/message_loop/message_pump_win.cc:480: LARGE_INTEGER due_time = {0};
FYI, when you reland this, please use {} instead of {0} to avoid tickling a
Clang warning.

Using {} instead of {0} also leads to slightly better codegen for VC:
https://randomascii.wordpress.com/2011/08/15/visual-c-code-gen-deficiencies/#3