summaryrefslogtreecommitdiffstats
path: root/base/message_loop/incoming_task_queue.h
diff options
context:
space:
mode:
authorananta <ananta@chromium.org>2015-06-21 23:10:42 -0700
committerCommit bot <commit-bot@chromium.org>2015-06-22 06:11:12 +0000
commit4d5496cde5b81436954e31a9fe82e35ccfe5de49 (patch)
tree2b793f863e11e18f216656f457d7aab4303fadc5 /base/message_loop/incoming_task_queue.h
parent9592add2c95e6a1b8caee96b4987b69d1140d4f5 (diff)
downloadchromium_src-4d5496cde5b81436954e31a9fe82e35ccfe5de49.zip
chromium_src-4d5496cde5b81436954e31a9fe82e35ccfe5de49.tar.gz
chromium_src-4d5496cde5b81436954e31a9fe82e35ccfe5de49.tar.bz2
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 Review URL: https://codereview.chromium.org/1194673004 Cr-Commit-Position: refs/heads/master@{#335475}
Diffstat (limited to 'base/message_loop/incoming_task_queue.h')
-rw-r--r--base/message_loop/incoming_task_queue.h3
1 files changed, 3 insertions, 0 deletions
diff --git a/base/message_loop/incoming_task_queue.h b/base/message_loop/incoming_task_queue.h
index 7dd1e82..544f3e9 100644
--- a/base/message_loop/incoming_task_queue.h
+++ b/base/message_loop/incoming_task_queue.h
@@ -57,6 +57,9 @@ class BASE_EXPORT IncomingTaskQueue
// scheduling work.
void StartScheduling();
+ // Returns the delay for the most recently added task.
+ TimeTicks GetNewlyAddedTaskDelay();
+
private:
friend class RefCountedThreadSafe<IncomingTaskQueue>;
virtual ~IncomingTaskQueue();