summaryrefslogtreecommitdiffstats
path: root/base/message_loop
Commit message (Collapse)AuthorAgeFilesLines
* Remove base::MessageLoop::{Quit,QuitClosure} functionski.stfu2015-10-233-11/+7
| | | | | | | | | | | | | This patch removes aliases for base::MessageLoop::QuitWhenIdle & base::MessageLoop::QuitWhenIdleClosure, and includes minor formatting changes made by using git cl-format. BUG=131220 TEST= R=danakj@chromium.org,brettw@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1390513002 Cr-Commit-Position: refs/heads/master@{#355763}
* Implement ThreadTicks::Now on Windows.fdoray2015-10-151-0/+5
| | | | | | | | | | | | | | | | | | | | Use QueryThreadCycleTime() to get the number of CPU clock cycles used by the current thread. Convert it to microseconds using a measured TSC frequency. The value returned by QueryThreadCycleTime() is based on the rdtsc instruction. For several years, Intel has been shipping CPUs with a constant-rate counter, which means that the QueryThreadCycleTime() results are directly proportional to wall-clock time on most systems (see crbug.com/280743#c15). ThreadTicks::IsSupported() will return false if the CPU doesn't have a constant rate TSC. BUG=280743 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review URL: https://codereview.chromium.org/1390743002 Cr-Commit-Position: refs/heads/master@{#354213}
* Remove all Windows Window Scoped Trackers and Associated Instrumentationrobliao2015-09-291-29/+1
| | | | | | | | | | | | The jank dashboard shows that there is nothing actionable remaining to do here. The sampling profiler should be able to supersede any manual tracking should we need to investigate future jank. BUG=440919 Review URL: https://codereview.chromium.org/1370993003 Cr-Commit-Position: refs/heads/master@{#351254}
* jni_generator: Pass object parameters as JavaParamRef.torne2015-09-041-2/+4
| | | | | | | | | | | | | | | | | | | Pass all object parameters to JNI functions in JavaParamRef<> wrappers. This new type behaves like ScopedJavaLocalRef, but does not free the local reference when it goes out of scope, since the JVM does not allow method parameters to be freed and this causes a warning. This CL only changes the implementation of the generator and the signatures of JNI functions which take JavaParamRef arguments; the minimum required to allow it to compile and work. An implicit cast from JavaParamRef<T> to T is defined, to allow function bodies to remain unaltered. These will be migrated over future CLs and the cast removed. BUG=506850 Review URL: https://codereview.chromium.org/1312153003 Cr-Commit-Position: refs/heads/master@{#347379}
* Reland of move 1 ms rounding up of task delays on Windows (patchset #1 id:1 ↵brucedawson2015-08-241-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of https://codereview.chromium.org/1304293002/ ) Reason for revert: The original change was reverted in error. The Webkit Win10 builder has been hitting multiple failures for a long time. Neither my change nor the revert affected this. And, the linked build failures (builds/71) were before my change landed. By reverting the revert of my undo of a previous change we are putting the code back to its original state (see original description) Original issue's description: > Revert of Remove 1 ms rounding up of task delays on Windows (patchset #1 id:1 of https://codereview.chromium.org/1305873002/ ) > > Reason for revert: > Figuring out if this could cause Win10 failures: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/71 > > Original issue's description: > > Remove 1 ms rounding up of task delays on Windows > > > > Prior to a couple of attempts at fixing bug 487724 the message pump > > would sometimes end up spinning for up to a ms when waiting for a > > message's time to arrive. This was unintentional and non-obvious. > > > > The eventual fix was to round up the delay time to the next ms. > > Unfortunately this caused a regression in smoothness.top_25_smooth > > which has not been resolved (investigation was delayed due to some > > confusion about the results). Therefore this change reverts both > > fix attempts in order to leave time for a proper investigation and > > any necessary fixes. > > > > It is worth mentioning that the delay introduced by rounding up to 1 > > ms is actually worse than expected on some operating systems. On Windows > > 7 a call to Sleep(1) will, if the timer frequency is raised, return > > within a ms. On Windows 8.1 it will often take two ms to return, which > > increases the delay. If the timer frequency is at its default interval > > of 15.625 ms then the delay can be longer. > > > > BUG=487724,497536 > > > > Committed: https://crrev.com/2b1bf190a079709a1a6a769bf86e782423d23121 > > Cr-Commit-Position: refs/heads/master@{#344688} > > TBR=rvargas@chromium.org,brucedawson@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=487724,497536 > > Committed: https://crrev.com/189fc2149ec370a0a42b1bb63e9b49fa579aa1d7 > Cr-Commit-Position: refs/heads/master@{#344798} TBR=rvargas@chromium.org,pfeldman@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=487724,497536 Review URL: https://codereview.chromium.org/1311863002 Cr-Commit-Position: refs/heads/master@{#345110}
* Fix top-level trace event name in MessageLoop::RunTaskcaseq2015-08-221-1/+1
| | | | | | | | | | | ... following a typo in https://codereview.chromium.org/1237283006 BUG=523345 TBR=danakj Review URL: https://codereview.chromium.org/1305283002 Cr-Commit-Position: refs/heads/master@{#344928}
* Revert of Remove 1 ms rounding up of task delays on Windows (patchset #1 ↵pfeldman2015-08-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:1 of https://codereview.chromium.org/1305873002/ ) Reason for revert: Figuring out if this could cause Win10 failures: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win10/builds/71 Original issue's description: > Remove 1 ms rounding up of task delays on Windows > > Prior to a couple of attempts at fixing bug 487724 the message pump > would sometimes end up spinning for up to a ms when waiting for a > message's time to arrive. This was unintentional and non-obvious. > > The eventual fix was to round up the delay time to the next ms. > Unfortunately this caused a regression in smoothness.top_25_smooth > which has not been resolved (investigation was delayed due to some > confusion about the results). Therefore this change reverts both > fix attempts in order to leave time for a proper investigation and > any necessary fixes. > > It is worth mentioning that the delay introduced by rounding up to 1 > ms is actually worse than expected on some operating systems. On Windows > 7 a call to Sleep(1) will, if the timer frequency is raised, return > within a ms. On Windows 8.1 it will often take two ms to return, which > increases the delay. If the timer frequency is at its default interval > of 15.625 ms then the delay can be longer. > > BUG=487724,497536 > > Committed: https://crrev.com/2b1bf190a079709a1a6a769bf86e782423d23121 > Cr-Commit-Position: refs/heads/master@{#344688} TBR=rvargas@chromium.org,brucedawson@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=487724,497536 Review URL: https://codereview.chromium.org/1304293002 Cr-Commit-Position: refs/heads/master@{#344798}
* Remove 1 ms rounding up of task delays on Windowsbrucedawson2015-08-211-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Prior to a couple of attempts at fixing bug 487724 the message pump would sometimes end up spinning for up to a ms when waiting for a message's time to arrive. This was unintentional and non-obvious. The eventual fix was to round up the delay time to the next ms. Unfortunately this caused a regression in smoothness.top_25_smooth which has not been resolved (investigation was delayed due to some confusion about the results). Therefore this change reverts both fix attempts in order to leave time for a proper investigation and any necessary fixes. It is worth mentioning that the delay introduced by rounding up to 1 ms is actually worse than expected on some operating systems. On Windows 7 a call to Sleep(1) will, if the timer frequency is raised, return within a ms. On Windows 8.1 it will often take two ms to return, which increases the delay. If the timer frequency is at its default interval of 15.625 ms then the delay can be longer. BUG=487724,497536 Review URL: https://codereview.chromium.org/1305873002 Cr-Commit-Position: refs/heads/master@{#344688}
* Prevent a thread startup race in ScheduleWorkTest which causes a nullptr ↵amistry2015-08-101-0/+7
| | | | | | | | dereference of a message pump. Review URL: https://codereview.chromium.org/1283543007 Cr-Commit-Position: refs/heads/master@{#342741}
* Cleanup message_loop.cclucinka.brozkova2015-08-071-1/+1
| | | | | | | | | Access kHexRangePrintingFlag through HistogramBase:: and not through instance variable. Accessing through instance variable is also correct, but confusing and can lead to future mistakes, because the variable is in this case null. BUG=517586 Review URL: https://codereview.chromium.org/1278613003 Cr-Commit-Position: refs/heads/master@{#342304}
* Microoptimisation for OnLibeventNotification.ricea2015-08-062-12/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OnLibeventNotification created a weak ptr to check that OnFileCanWriteWithoutBlocking() has not deleted theFileDescriptorWatcher object. Creating a WeakPtr performs an allocation. OnLibeventNotification is called often enough that it accounted for roughly 5% of the allocations performed by the browser. The allocation can be avoided by using a boolean variable to flag whether or not the FileDescriptorWatcher object has been destroyed. Furthermore, when only one of OnFileCanWriteWithoutBlocking() and OnFileCanReadWithoutBlocking() is going to be called, it is not necessary to check whether the FileDescriptorWatcher has been destroyed at all. Results from running the IPCChannelPerfTest.ChannelPingPong performance test with and without this change (all times in ms): IPC_Channel_Perf_50000x_12: 542.8 (s = 6.1) to 524.5 (s = 4.0) IPC_Channel_Perf_50000x_144: 552.8 (s = 6.8) to 537.2 (s = 5.1) IPC_Channel_Perf_50000x_1728: 572.5 (s = 6.7) to 553.7 (s = 6.7) IPC_Channel_Perf_12000x_20736: 305.7 (s = 4.2) to 305.1 (s = 3.2) IPC_Channel_Perf_1000x_248832: 365.0 (s = 3.7) to 361.3 (s = 2.9) My test environment was too noisy to demonstrate a statistically significant improvement on the last two cases, but I think it should be possible. BUG= TEST=base_unittests, net_unittests Review URL: https://codereview.chromium.org/1255293006 Cr-Commit-Position: refs/heads/master@{#342076}
* Proof-reading comments in base/message_loop/.qyearsley2015-07-259-27/+27
| | | | | | | | | This CL contains a few minor changes to comments that I made while skimming through the code. Mostly spelling changes. Review URL: https://codereview.chromium.org/1255673004 Cr-Commit-Position: refs/heads/master@{#340383}
* base: Cast completion key, overlapped and this pointers to void* before ↵pcc2015-07-171-2/+2
| | | | | | | | | | | | | | comparison. This is a cleanup for -fsanitize=cfi-unrelated-cast; we were previously casting between the unrelated types MessagePumpForIO and IOHandler. BUG=457523,507755 R=cpu@chromium.org,ananta@chromium.org Review URL: https://codereview.chromium.org/1219023007 Cr-Commit-Position: refs/heads/master@{#339228}
* Extract trace from TaskAnnotator::RunTask to its call sitescaseq2015-07-161-2/+4
| | | | | | | | | | | | | This extracts TRACE_EVENT() that brackets the task being executed from TaskAnnotator::RunTask() to its call sites, so that it covers time spent in the task observers on the top level (i.e. in MessageLoop). BUG=508005 TBR=chirantan Review URL: https://codereview.chromium.org/1237283006 Cr-Commit-Position: refs/heads/master@{#339091}
* Revert of Trace MessageLoop::RunTask execution (patchset #2 id:20001 of ↵caseq2015-07-141-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/1225333002/) Reason for revert: Regressed perf on Nexus 7 BUG=509982,508005 Original issue's description: > Trace MessageLoop::RunTask execution > > Previously, we were only issuing trace events around the task execution > within TaskAnnotator::RunTask. However, this does not include time spent > in observers (see bug for details on how it bites). > > BUG=508005 > > Committed: https://crrev.com/87a2c639ff073ed3194a788ee1eaf82aabe77bab > Cr-Commit-Position: refs/heads/master@{#338492} TBR=danakj@chromium.org,dsinclair@chromium.org,nduca@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=508005 Review URL: https://codereview.chromium.org/1234573005 Cr-Commit-Position: refs/heads/master@{#338676}
* base: Make it possible to replace the MessageLoop's task runnerskyostil2015-07-133-6/+65
| | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to customize the task posting behavior of a MessageLoop. More specifically, a client can change the value returned by MessageLoop::task_runner() as well as ThreadTaskRunnerHandle::Get() on the target thread. The original task runner can still be used to post tasks to be run on the message loop. The Blink/renderer scheduler will use this functionality to manage task posting on the renderer main thread. This is needed to ensure consistent ordering of tasks posted through the MessageLoop w.r.t. tasks posted to the scheduler. Design doc: https://docs.google.com/a/chromium.org/document/d/1qxdh2I61_aB_Uzh1QgNqvdWFBCL_E65G2smoSySw7KU/edit# Alex Clarke <alexclarke@chromium.org> also contributed to this patch (https://codereview.chromium.org/1206893003/). BUG=465354 Review URL: https://codereview.chromium.org/998063002 Cr-Commit-Position: refs/heads/master@{#338564}
* Trace MessageLoop::RunTask executioncaseq2015-07-131-0/+2
| | | | | | | | | | | | Previously, we were only issuing trace events around the task execution within TaskAnnotator::RunTask. However, this does not include time spent in observers (see bug for details on how it bites). BUG=508005 Review URL: https://codereview.chromium.org/1225333002 Cr-Commit-Position: refs/heads/master@{#338492}
* Revert of base: Make it possible to replace the MessageLoop's task runner ↵glider2015-07-133-55/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #7 id:120001 of https://codereview.chromium.org/998063002/) Reason for revert: Reverting this CL because of https://crbug.com/508789 Please fix and test using the linux_chromium_tsan_rel_ng trybot. Original issue's description: > base: Make it possible to replace the MessageLoop's task runner > > This patch makes it possible to customize the task posting behavior > of a MessageLoop. More specifically, a client can change the value > returned by MessageLoop::task_runner() as well as > ThreadTaskRunnerHandle::Get() on the target thread. The original task > runner can still be used to post tasks to be run on the message loop. > > The Blink/renderer scheduler will use this functionality to manage task > posting on the renderer main thread. This is needed to ensure consistent > ordering of tasks posted through the MessageLoop w.r.t. tasks posted to > the scheduler. > > Design doc: https://docs.google.com/a/chromium.org/document/d/1qxdh2I61_aB_Uzh1QgNqvdWFBCL_E65G2smoSySw7KU/edit# > > Alex Clarke <alexclarke@chromium.org> also contributed to this patch (https://codereview.chromium.org/1206893003/). > > BUG=465354 > > Committed: https://crrev.com/698e77997894bf823c45ad1d6e0764fa93e2f3c1 > Cr-Commit-Position: refs/heads/master@{#337799} TBR=jam@chromium.org,danakj@chromium.org,alexclarke@google.com,kinuko@chromium.org,skyostil@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=465354 Review URL: https://codereview.chromium.org/1223193004 Cr-Commit-Position: refs/heads/master@{#338484}
* [Mac] Redo NSException handling, and generate better stacks for C++ exceptions.rsesek2015-07-101-15/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces base::mac::CallWithEHFrame(), which will run a block in a stack frame that is set up to stop searching for an exception handler when it is reached. This is used to prevent a top-level exception handler, installed in CFRunLoopRunSpecific(), from catching and rethrowing C++ exceptions. When it does this, the resulting stack traces are not useful for triage purposes. By stoping the search for an exception handler, the runtime will call std::terminate directly from the throwing stack trace. In addition, NSException handling is converted from swizzling the designated initializer to an ObjC 2.0 exception preprocessor. Some exceptions could still escape this mechanism, if they are thrown without CallWithEHFrame() on the stack. This could happen if the exception were thrown outside of the MessagePump's work sources or -sendEvent:. Possible situations are things like the CFRunLoop block and Mach port callouts. This shouldn't happen from Chromium code, so it would only affect system-thrown exceptions. These exceptions would still be fatal, just with the less-useful run loop stack. To summarize: all uncaught exceptions are fatal one way or another. If the exception isn't caught before it unwinds to CallWithEHFrame, the crash will have an immediately actionable stack from the point of throw. If the exception is caught by the run loop or some other top-level exception handler, the exception will be rethrown and the crash stack will be less useful. In that case, if it's an ObjC exception, a crash key will still record a trace from the point-of- throw. Using try/catch is now unrestricted, and no special whitelist is maintained to allow certain NSExceptions to be alloc/init'd. BUG=503128 R=shess@chromium.org, thakis@chromium.org Review URL: https://codereview.chromium.org/1212093002 Cr-Commit-Position: refs/heads/master@{#338332}
* base: Make it possible to replace the MessageLoop's task runnerskyostil2015-07-083-6/+55
| | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to customize the task posting behavior of a MessageLoop. More specifically, a client can change the value returned by MessageLoop::task_runner() as well as ThreadTaskRunnerHandle::Get() on the target thread. The original task runner can still be used to post tasks to be run on the message loop. The Blink/renderer scheduler will use this functionality to manage task posting on the renderer main thread. This is needed to ensure consistent ordering of tasks posted through the MessageLoop w.r.t. tasks posted to the scheduler. Design doc: https://docs.google.com/a/chromium.org/document/d/1qxdh2I61_aB_Uzh1QgNqvdWFBCL_E65G2smoSySw7KU/edit# Alex Clarke <alexclarke@chromium.org> also contributed to this patch (https://codereview.chromium.org/1206893003/). BUG=465354 Review URL: https://codereview.chromium.org/998063002 Cr-Commit-Position: refs/heads/master@{#337799}
* Revert of Don't peek messages in the MessagePumpForUI class when we receive ↵jbauman2015-07-017-158/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | our kMsgHaveWork message. (patchset #2 id:20001 of https://codereview.chromium.org/1194673004/) Reason for revert: Causes one 1 task to run per 3 ms when in a nested modal loop, which causes resize to lag behind. BUG=505612 Original issue's description: > 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} TBR=scottmg@chromium.org,cpu@chromium.org,brucedawson@chromium.org,kbr@chromium.org,ananta@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=492837, 501602 Review URL: https://codereview.chromium.org/1222013004 Cr-Commit-Position: refs/heads/master@{#337113}
* MessageLoop: wire the unused static method in base::Thread (follow-up cleanup)kinuko2015-06-301-1/+1
| | | | | | | | | | | | | | | | Actually use the private static method (CreateUnbound) in base::Thread. I added the method in the last refactoring patch but forgot to use it; I can either remove the static method or use it, I do the latter in this patch as I thought leaving the private ctor of MessageLoop only for delegated use-case cleaner. BUG=465458 R=thakis@chromium.org Review URL: https://codereview.chromium.org/1212193003 Cr-Commit-Position: refs/heads/master@{#336710}
* Don't peek messages in the MessagePumpForUI class when we receive our ↵ananta2015-06-227-56/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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}
* Delete watcher on IO thread in MessagePumpLibeventTest.QuitWatcher.derekjchow2015-06-211-2/+6
| | | | | | | | | | | | | If StartWatching is run before the WaitableEvent is signaled, the StopWatching should be called (on the IO thread). Otherwise, a DCHECK will be called in the destructor of WaitableEventWatcher. BUG=internal b/21093761 BUG=481290 Review URL: https://codereview.chromium.org/1184093007 Cr-Commit-Position: refs/heads/master@{#335451}
* base: Remove MessageLoopProxyskyostil2015-06-199-301/+174
| | | | | | | | BUG=465354 Review URL: https://codereview.chromium.org/1180153002 Cr-Commit-Position: refs/heads/master@{#335277}
* Revert of Don't peek messages in the MessagePumpForUI class when we receive ↵scottmg2015-06-187-131/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | our kMsgHaveWork message. (patchset #1 id:1 of https://codereview.chromium.org/1173193002/) Reason for revert: Causing frequent wakeups (especially with watcher process?) and shows power regression on perf bots https://code.google.com/p/chromium/issues/detail?id=500749. Potential fix at https://codereview.chromium.org/1189133003/ Original issue's description: > Don't peek messages in the MessagePumpForUI class when we receive our kMsgHaveWork message. > > Relanding this patch with fixes for content_unittests failures. We need to wait for the UI worker thread to start. > > 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 > TBR=cpu, scottmg > > Committed: https://crrev.com/29a20657bb92335c4e671cc1ee4c5e36ee1ffa1b > Cr-Commit-Position: refs/heads/master@{#333831} TBR=cpu@chromium.org,ananta@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=492837,500749 Review URL: https://codereview.chromium.org/1181263008 Cr-Commit-Position: refs/heads/master@{#335082}
* Disable MessagePumpLibeventTest.TestWatchingFromBadThread on Linux.Steve Kobes2015-06-121-2/+2
| | | | | | | | | BUG=138845 TBR=chirantan@chromium.org Review URL: https://codereview.chromium.org/1180243002. Cr-Commit-Position: refs/heads/master@{#334258}
* Don't peek messages in the MessagePumpForUI class when we receive our ↵ananta2015-06-107-55/+131
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | kMsgHaveWork message. Relanding this patch with fixes for content_unittests failures. We need to wait for the UI worker thread to start. 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 TBR=cpu, scottmg Review URL: https://codereview.chromium.org/1173193002 Cr-Commit-Position: refs/heads/master@{#333831}
* Disable MessagePumpLibeventTest.TestWatchingFromBadThread on Chrome OSkjellander2015-06-101-1/+7
| | | | | | | | | BUG=138845 TBR=chirantan@chromium.org Review URL: https://codereview.chromium.org/1172283002 Cr-Commit-Position: refs/heads/master@{#333719}
* Revert of Don't peek messages in the MessagePumpForUI class when we receive ↵kjellander2015-06-107-130/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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}
* Don't peek messages in the MessagePumpForUI class when we receive our ↵ananta2015-06-097-55/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 Review URL: https://codereview.chromium.org/1156503005 Cr-Commit-Position: refs/heads/master@{#333572}
* Remove Unactionable or Low Jank USER32 Instrumentationrobliao2015-06-021-26/+0
| | | | | | | | | | USER32 calls generally do not have an SLA on returning promptly. They do however, generally need to be called on the thread that created the hwnd. There's not much we can do with these calls. BUG=470226 Review URL: https://codereview.chromium.org/1163863003 Cr-Commit-Position: refs/heads/master@{#332322}
* Fixit: Fork base::TimeTicks --> TimeTicks + ThreadTicks + TraceTicksmiu2015-05-291-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | TimeTicks was being overused for time values from three different clock sources. This change splits the class into three separate classes: The general-purpose monotonic time (TimeTicks), the thread-local run time (ThreadTicks), and the global system trace time (TraceTicks). With this change, the compiler is now able to use type-checking to guarantee values from different clocks are not being mixed when doing time math. This is the 2nd in a two-part change. Part 1 factored-out the comparison and math operator overloads common to base::Time and base::TimeTicks into a templated base class. The new ThreadTicks and TraceTicks time classes also inherit from that base class. Updated base/trace_event/* and a handful of outside-of-base uses of ThreadNow() and NowFromSystemTraceTime() to use the new classes. A bug was identified and fixed, in src/ui/gl/angle_platform_impl.cc, where values from TimeTicks::Now() were being erroneously provided to base::TraceEvent instead of values from NowFromSystemTraceTime(). BUG=467417 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel NOTRY=true Review URL: https://codereview.chromium.org/1122153002 Cr-Commit-Position: refs/heads/master@{#332080}
* Reland (3rd try): Lazily initialize MessageLoop for faster thread startupkinuko2015-05-237-57/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Original review: https://codereview.chromium.org/1011683002/ 2nd try: https://codereview.chromium.org/1129953004/ 2nd try reverted due to race reports on Linux: https://crbug.com/489263 Data races on valid_thread_id_ after r330329 This fixes: - Race in MessageLoopProxyImpl by introducing lock - Race in BrowserMainLoop/BrowserThreadImpl, where BrowserThread::CurrentlyOn() called on one of BrowserThreads tries to touch other thread's message_loop() via global thread table. Reg: the latter race, the code flow that causes this race is like following: // On the main thread, we create all known browser threads: for (...) { { AutoLock lock(g_lock); g_threads[id] = new BrowserProcessSubThread(); } // [A] This initializes the thread's message_loop, which causes a race // against [B] in the new code because new threads can start running // immediately. thread->StartWithOptions(); } // On the new thread's main function, it calls CurrentlyOn() which does: { // [B] This touches other thread's Thread::message_loop. AutoLock lock(g_lock); return g_threads[other_thread_id] && g_threads[other_thread_id]->message_loop() == MessageLoop::current(); } This was safe before because both message_loop initialization and the first call to CurrentlyOn() on the new thread was done synchronously in StartWithOptions() while the main thread was blocked. In the new code new threads can start accessing message_loop() asynchronously while the main thread's for loop is running. PS1 is the original patch (2nd try) that got reverted. BUG=465458, 489263 Review URL: https://codereview.chromium.org/1131513007 Cr-Commit-Position: refs/heads/master@{#331235}
* Set minimum Windows wait time to 1 ms in MessagePumpDefault::Runbrucedawson2015-05-231-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | On Windows if we call event_.TimedWait(delay); with a sub-ms delay then the wait function will return immediately. This means we end up busy waiting down to zero. Rounding these times up to 1 ms lets Chrome go idle and saves a few percent of a core on some tests. The symptom to watch for is lots of time being spent in QPCNow, called from MessagePumpDefault::Run or from MessageLoop::DoDelayedWork. This is the second attempt at fixing this bug. The first attempt tried rounding down the short delays but this was stymied by other code that didn't respect the rounding down. One known problem is that some animations that try to run at 60 fps by using setInterval(C,16) will drop from ~60 fps to ~58 fps. Those that use requestAnimationFrame run at a steady rate of 60 fps. BUG=487724 Review URL: https://codereview.chromium.org/1154953002 Cr-Commit-Position: refs/heads/master@{#331226}
* Process pending delayed tasks in kMsgHaveWorkjbauman2015-05-202-40/+49
| | | | | | | | | | | With 1 win32 timer we can only get a callback every 10ms, and since the callback only processes one message, that means the queue could keep growing if delayed tasks are posted faster than that rate, even if they're processed very quickly. To prevent that, schedule a kMsgHaveWork if there's 0ms until the next delayed task should run, and run a delayed task in the kMsgHaveWork handler. BUG=454333 TEST=chrome resizes smoothly Review URL: https://codereview.chromium.org/918473002 Cr-Commit-Position: refs/heads/master@{#330816}
* Revert of Reland: Lazily initialize MessageLoop for faster thread startup ↵glider2015-05-187-128/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | (patchset #5 id:160001 of https://codereview.chromium.org/1129953004/) Reason for revert: Massive data race reports, see https://crbug.com/489263 Original issue's description: > Reland: Lazily initialize MessageLoop for faster thread startup > > Original review: https://codereview.chromium.org/1011683002/ > > Reverted because it's suspected for following flakiness issues: > http://crbug.com/485157 - Windows race > http://crbug.com/485091 - Android ThreadWatcher > http://crbug.com/485178 - interactive_ui_tests Menu* tests > > PS1 is the original patch set that gets reverted. > > BUG=465458, 485157, 485091, 485178 > TBR=jam > > Committed: https://crrev.com/8b6133a69f16702a32a3c3104630c4d9ac393b7a > Cr-Commit-Position: refs/heads/master@{#330329} TBR=thakis@chromium.org,toyoshim@chromium.org,jam@chromium.org,kinuko@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=465458, 485157, 485091, 485178 Review URL: https://codereview.chromium.org/1140363002 Cr-Commit-Position: refs/heads/master@{#330351}
* Reland: Lazily initialize MessageLoop for faster thread startupkinuko2015-05-187-56/+128
| | | | | | | | | | | | | | | | | | Original review: https://codereview.chromium.org/1011683002/ Reverted because it's suspected for following flakiness issues: http://crbug.com/485157 - Windows race http://crbug.com/485091 - Android ThreadWatcher http://crbug.com/485178 - interactive_ui_tests Menu* tests PS1 is the original patch set that gets reverted. BUG=465458, 485157, 485091, 485178 TBR=jam Review URL: https://codereview.chromium.org/1129953004 Cr-Commit-Position: refs/heads/master@{#330329}
* Treat a delay of under 1 millisecond in MessagePumpDefault as a signal that ↵ananta2015-05-151-1/+2
| | | | | | | | | | | | | | | | | 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 Review URL: https://codereview.chromium.org/1137453006 Cr-Commit-Position: refs/heads/master@{#329997}
* Revert of Lazily initialize MessageLoop for faster thread startup (patchset ↵kinuko2015-05-077-128/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #28 id:870001 of https://codereview.chromium.org/1011683002/) Reason for revert: This introduced flaky assertion failure on some tests http://crbug.com/485157 Original issue's description: > Lazily initialize MessageLoop for faster thread startup > > Summary of the change and background discussion: > https://docs.google.com/a/chromium.org/document/d/1o1vUUOjX3tC7pV5-nxchaGtElo4NwtzKOAb4Zm09ezw/edit# > > This implements approach 1 in the doc. > Approach 2: https://codereview.chromium.org/1086663002/ > Approach 3: https://codereview.chromium.org/1058603004/ > > Discussion thread: > https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/2t6lB8hUgYw > > BUG=465458 > > Committed: https://crrev.com/f1f70cb5ebe24d85c575396f026a415ed0fe9afc > Cr-Commit-Position: refs/heads/master@{#328347} TBR=dalecurtis@chromium.org,rvargas@chromium.org,tommi@chromium.org,mark@chromium.org,thakis@chromium.org,danakj@chromium.org,pauljensen@chromium.org,jam@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=465458 Review URL: https://codereview.chromium.org/1122383003 Cr-Commit-Position: refs/heads/master@{#328674}
* Lazily initialize MessageLoop for faster thread startupkinuko2015-05-057-56/+128
| | | | | | | | | | | | | | | | | | Summary of the change and background discussion: https://docs.google.com/a/chromium.org/document/d/1o1vUUOjX3tC7pV5-nxchaGtElo4NwtzKOAb4Zm09ezw/edit# This implements approach 1 in the doc. Approach 2: https://codereview.chromium.org/1086663002/ Approach 3: https://codereview.chromium.org/1058603004/ Discussion thread: https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/2t6lB8hUgYw BUG=465458 Review URL: https://codereview.chromium.org/1011683002 Cr-Commit-Position: refs/heads/master@{#328347}
* Adding a comment to message_loop_proxy.h informing developers of its ↵anujk.sharma2015-05-051-0/+12
| | | | | | | | | | | | | | | | deprecation. base::MessageLoopProxy::current() -> base::ThreadTaskRunnerHandle::Get() scoped_refptr<base::MessageLoopProxy> -> scoped_refptr<base::SingleThreadTaskRunner> base::MessageLoopProxy -> base::SingleThreadTaskRunner BUG=391045 Review URL: https://codereview.chromium.org/1109933004 Cr-Commit-Position: refs/heads/master@{#328294}
* Add toplevel trace event to MessagePumpLibevent::OnLibeventNotificationspang2015-04-241-0/+3
| | | | | | | | | | | | | | This adds a new top level trace span for work resulting from I/O notifications. Currently I/O triggered work may not show up at all in tracing (unlike work resulting from PostTask). BUG=none TEST=chrome://tracing on Chromebook Pixel. Input thread shows I/O spans rather than showing nothing. Review URL: https://codereview.chromium.org/1097283004 Cr-Commit-Position: refs/heads/master@{#326855}
* Apply automated fixits for Chrome clang plugin to base_unittests.dcheng2015-04-172-4/+5
| | | | | | | | | | Working on trimming down ~26k warnings on the Windows clang build. BUG=467287 Review URL: https://codereview.chromium.org/1092863002 Cr-Commit-Position: refs/heads/master@{#325606}
* win: Fix a few clang style plugin warnings.Nico Weber2015-04-162-10/+16
| | | | | | | | | BUG=467287 R=dcheng@chromium.org Review URL: https://codereview.chromium.org/1095653002 Cr-Commit-Position: refs/heads/master@{#325513}
* Re-land: Add missing check for quitting from MessagePumpLibeventchirantan2015-04-032-3/+73
| | | | | | | | | | | | | | | If a MessagePumpLibevent has no tasks to run, it will call libevent's event_base_loop with EVLOOP_ONCE. However, it may turn out that the event that finally runs actually quits the MessageLoop. In this case, there is an off-by-one error where MessagePumpLibevent will call the MessageLoop's DoWork function once before realizing that it was actually asked to quit. Add a check to prevent this from happening. BUG=473693 Review URL: https://codereview.chromium.org/1059353003 Cr-Commit-Position: refs/heads/master@{#323834}
* Revert of Add missing check for quitting from MessagePumpLibevent (patchset ↵zhaoqin2015-04-032-63/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | #3 id:40001 of https://codereview.chromium.org/1019793006/) Reason for revert: Data race reported by TSan at http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20TSan%20Tests/builds/2153 BUG=473693 Original issue's description: > Add missing check for quitting from MessagePumpLibevent > > If a MessagePumpLibevent has no tasks to run, it will call libevent's > event_base_loop with EVLOOP_ONCE. However, it may turn out that the > event that finally runs actually quits the MessageLoop. In this case, > there is an off-by-one error where MessagePumpLibevent will call the > MessageLoop's DoWork function once before realizing that it was actually > asked to quit. Add a check to prevent this from happening. > > BUG=none TBR=thestig@chromium.org,sadrul@chromium.org,chirantan@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=none Review URL: https://codereview.chromium.org/1060593002 Cr-Commit-Position: refs/heads/master@{#323746}
* Add missing check for quitting from MessagePumpLibeventchirantan2015-04-032-3/+63
| | | | | | | | | | | | | | | If a MessagePumpLibevent has no tasks to run, it will call libevent's event_base_loop with EVLOOP_ONCE. However, it may turn out that the event that finally runs actually quits the MessageLoop. In this case, there is an off-by-one error where MessagePumpLibevent will call the MessageLoop's DoWork function once before realizing that it was actually asked to quit. Add a check to prevent this from happening. BUG=none Review URL: https://codereview.chromium.org/1019793006 Cr-Commit-Position: refs/heads/master@{#323657}
* base: Mark MessageLoop::Post*Task API deprecatedskyostil2015-03-212-8/+9
| | | | | | | | | | | | | | This is the first step in removing the direct MessageLoop task posting API in favor of task_runner() and the TaskRunner APIs. See the design doc for details[1]. BUG=465354 [1] https://docs.google.com/a/chromium.org/document/d/1qxdh2I61_aB_Uzh1QgNqvdWFBCL_E65G2smoSySw7KU/edit#heading=h.eqrpa9q6bsq5 Review URL: https://codereview.chromium.org/1013813003 Cr-Commit-Position: refs/heads/master@{#321674}
* base: Fix/add header #ifndef guards.danakj2015-03-102-4/+4
| | | | | | | | | | | | | | | | Header guards should be defined based on the path and file name of the header file. Some headers have it wrong, some are missing the guards, and some just have the matching comment wrong. R=Nico BUG=464816 Committed: https://crrev.com/301b392761fd8f66f3a701ab1dd011c6e7a55e19 Cr-Commit-Position: refs/heads/master@{#319722} Review URL: https://codereview.chromium.org/985003004 Cr-Commit-Position: refs/heads/master@{#319793}
generated by cgit v1.1 at 2025-02-08 12:42:01 +0000