summaryrefslogtreecommitdiffstats
path: root/base/message_loop_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* GTTF: Add bug reference to failing tests:phajdan.jr@chromium.org2010-07-261-0/+2
| | | | | | | | | | | | | MessageLoopTest.EnsureTaskDeletion and MessageLoopTest.EnsureTaskDeletion_Chain TBR=darin TEST=MessageLoopTest.EnsureTaskDeletion and MessageLoopTest.EnsureTaskDeletion_Chain BUG=50272 Review URL: http://codereview.chromium.org/3044025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53687 0039d316-1c4b-4281-b951-d872f2087c98
* Random bits of header and whitespace cleanup.thestig@chromium.org2010-07-231-6/+8
| | | | | | | | BUG=none TEST=noe Review URL: http://codereview.chromium.org/3062003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53437 0039d316-1c4b-4281-b951-d872f2087c98
* Change chrome from statically enabling high resolution timers on windowsmbelshe@chromium.org2010-06-291-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | to enabling them dynamically - only when the application really needs them. I am working on some test cases for this, and will add them. But wanted to send out the concept for review. In this implementation, I modify the message loop to detect when the application has requested high resolution timers. Note that there are multiple MessageLoops active in a single process. After a period of time, we simply shut it off again. We could have set a timer or kept a count of active timers, or any number of more complex algorithms. But I think this algorithm is very simple and good enough. If an application continues needing high resolution timers for more than 1s, we'll turn the high-resolution timers back on again. One last change - since we've implemented the clamp at 4ms, there isn't a lot of point to our use of 1ms for timeBeginPeriod. I've modified that to 2 (which is half of 4ms, our target minimal interval). BUG=46531 TEST=MessageLoop.HighResolutionTimers Review URL: http://codereview.chromium.org/2822035 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@51102 0039d316-1c4b-4281-b951-d872f2087c98
* Clang: Do not ignore result of HANDLE_EINTR.thakis@chromium.org2010-06-231-4/+8
| | | | | | Review URL: http://codereview.chromium.org/2805026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50556 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 49982 - patchthakis@chromium.org2010-06-161-8/+4
| | | | | | | TBR=thakis@chromium.org Review URL: http://codereview.chromium.org/2825006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@50002 0039d316-1c4b-4281-b951-d872f2087c98
* patchthakis@chromium.org2010-06-161-4/+8
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49982 0039d316-1c4b-4281-b951-d872f2087c98
* TTF: Re-Re-enable MessageLoopTest.FileDescriptorWatcherOutlivesMessageLoop asjhawkins@chromium.org2010-06-111-4/+1
| | | | | | | | | | | it was inappropriately disabled due to Valgrind errors. BUG=none TEST=none Review URL: http://codereview.chromium.org/2780007 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49474 0039d316-1c4b-4281-b951-d872f2087c98
* Reland r49188.willchan@chromium.org2010-06-091-8/+73
| | | | | | | | It was reverted due to breaking a valgrind test which has since been disabled. Review URL: http://codereview.chromium.org/2763004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49320 0039d316-1c4b-4281-b951-d872f2087c98
* Revert 48102 - this test is now failing again, apparently since r49188 ↵joth@chromium.org2010-06-091-1/+2
| | | | | | | | | | | | | | | | | | | | landed. As it is not clear this test was enabled due to the functionality it test being required (indeed, the comment still states it is not), disabling it again to get the tree open. Original description from reverted change r48102: TTF: Re-enable the FileDescriptorWatcherOutlivesMessageLoop test as it now appears to be passing. BUG=none TEST=MessageLoopTest.FileDescriptorWatcherOutlivesMessageLoop Patch by Doug Muir <dmuir@google.com>. Review URL: http://codereview.chromium.org/2077014 TBR=jhawkins@chromium.org Review URL: http://codereview.chromium.org/2789002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49241 0039d316-1c4b-4281-b951-d872f2087c98
* Rebaseline tests whose expectations were changed by r55714.hamaji@chromium.org2010-06-091-73/+8
| | | | | | | | | | | | The patch removed extra paddings inside buttons. http://trac.webkit.org/changeset/55714 BUG=1437 TEST=none Review URL: http://codereview.chromium.org/789003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49225 0039d316-1c4b-4281-b951-d872f2087c98
* Jankometer: Generalize the code more. Add better support for monitoring IO ↵willchan@chromium.org2010-06-081-8/+73
| | | | | | | | | | | | | thread. Previously, the Jankometer only monitored windows messages on the UI thread (or gtk events). I've added observers for tasks and IO events. This lets us monitor all events on UI & IO threads (UI messages, all Tasks, and IO events). Replaces the JankObserver with a UIJankObserver and an IOJankObserver. Shares common code in JankObserverHelper. The JankObserverHelper and JankWatchdog are generic enough that they can probably move out to chrome/common and be reused by the renderer. Review URL: http://codereview.chromium.org/2098020 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@49188 0039d316-1c4b-4281-b951-d872f2087c98
* TTF: Re-enable MessageLoopTest.EnsureTaskDeletion* by marking them as failing.jhawkins@chromium.org2010-05-251-3/+6
| | | | | | | | TBR=stuartmorgan BUG=none TEST=MessageLoopTest.EnsureTaskDeletion* git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48184 0039d316-1c4b-4281-b951-d872f2087c98
* TTF: Re-enable the FileDescriptorWatcherOutlivesMessageLoop test as it now ↵jhawkins@chromium.org2010-05-241-2/+1
| | | | | | | | | | | | | | | appears to be passing. BUG=none TEST=MessageLoopTest.FileDescriptorWatcherOutlivesMessageLoop Patch by Doug Muir <dmuir@google.com>. Review URL: http://codereview.chromium.org/2077014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@48102 0039d316-1c4b-4281-b951-d872f2087c98
* Disable MessageLoopTest.RecursiveDenial2 since it is flaky and hangs.maruel@chromium.org2010-05-191-1/+2
| | | | | | | | | TEST=disabled BUG=44567 Review URL: http://codereview.chromium.org/2095013 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@47662 0039d316-1c4b-4281-b951-d872f2087c98
* Replace #if 0 used to disable test, the DISABLED_ and FLAKY_phajdan.jr@chromium.org2010-05-081-4/+2
| | | | | | | | | | | prefixes, so the code doesn't rot. TEST=none BUG=none Review URL: http://codereview.chromium.org/2035009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46782 0039d316-1c4b-4281-b951-d872f2087c98
* Support dragging a virtual file out of the browser.jianli@chromium.org2010-01-151-1/+42
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/351029 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36378 0039d316-1c4b-4281-b951-d872f2087c98
* Changes to base/ from a combination of FreeBSD and OpenBSD patches.evan@chromium.org2009-12-291-1/+1
| | | | | | Review URL: http://codereview.chromium.org/495002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@35321 0039d316-1c4b-4281-b951-d872f2087c98
* First patch in making destructors of refcounted objects private.jam@chromium.org2009-11-051-0/+9
| | | | | | | BUG=26749 Review URL: http://codereview.chromium.org/360042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31136 0039d316-1c4b-4281-b951-d872f2087c98
* Allow work that was deferred on account of not being runnable in a nested loopmark@chromium.org2009-06-251-16/+54
| | | | | | | | | | to be processed when returning to an outer loop. BUG=11470 13442 13468 TEST=base_unittests, test cases in bugs Review URL: http://codereview.chromium.org/146006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19272 0039d316-1c4b-4281-b951-d872f2087c98
* StopWatchingFileDescriptor needs to free struct event.dkegel@google.com2009-04-221-0/+75
| | | | | | | | | | | Also, there's no point in using scoped_ptr for event_ anymore, so removed that. Should fix http://crbug.com/10503 "Crash in network layer" Review URL: http://codereview.chromium.org/87045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14233 0039d316-1c4b-4281-b951-d872f2087c98
* Switch MessagePumpForIO to use completion ports on Windows.rvargas@google.com2008-11-071-99/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cleanup the separation between MessagePumpForUI and MessagePumpForIO, and convert the latter to use Completion Ports instead of MsgWaitForMultipleobjects to sleep when idle. Remove all traces of Windows messages from MessagePumpForIO, remove the transitional API of completion port notifications and remove WatchObject API. Modify all callers of RegisterIOHandler so that they are no longer using RegisterIOContext, and also handle properly the new semantics of completion ports (notifications even when the IO completes immediately). Add a new interface to allow proper cleanup of disk cache (to replace code that was waiting for pending APCs from the destructor). Add a way for the message pump to perform cleanup of abandoned IO. BUG=B/1344358, 3497, 3630 TESt=unit tests R=darin Review URL: http://codereview.chromium.org/8156 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5021 0039d316-1c4b-4281-b951-d872f2087c98
* Move Time, TimeDelta and TimeTicks into namespace base.dsh@google.com2008-10-271-0/+2
| | | | | | Review URL: http://codereview.chromium.org/7995 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@4022 0039d316-1c4b-4281-b951-d872f2087c98
* Add a way to register for completion-ports based async operations to be handledrvargas@google.com2008-10-091-7/+108
| | | | | | | | | | | through the windows version of the message pump. As a first step, actual IO processing is still performed using WatchObject instead of using completion ports. Review URL: http://codereview.chromium.org/1950 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3157 0039d316-1c4b-4281-b951-d872f2087c98
* fix oopsdarin@chromium.org2008-09-231-4/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2510 0039d316-1c4b-4281-b951-d872f2087c98
* Always use the topmost delayed task as the basis for our WM_TIMER.darin@chromium.org2008-09-231-0/+112
| | | | | | | | | R=jar BUG=2559 Review URL: http://codereview.chromium.org/4041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2509 0039d316-1c4b-4281-b951-d872f2087c98
* disable tests that are not ready to be enabled yetdarin@chromium.org2008-09-101-0/+3
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1961 0039d316-1c4b-4281-b951-d872f2087c98
* Put back r1891 with some task deletion disabled to maintain backwards compat ↵darin@chromium.org2008-09-101-0/+58
| | | | | | | | | | and thereby avoid unexpected crashes. r=jar Review URL: http://codereview.chromium.org/1664 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1959 0039d316-1c4b-4281-b951-d872f2087c98
* rollback r1891darin@google.com2008-09-091-58/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1892 0039d316-1c4b-4281-b951-d872f2087c98
* Delete pending tasks that have not run. To do this properly, I found that I ↵darin@google.com2008-09-091-0/+58
| | | | | | | | | | | | cannot clear MessageLoop::current() until all of the tasks have been deleted. I wrote a loop to make sure that the queues are all empty. This could be abused, obviously. Another approach would be to CHECK that the second loop doesn't do anything. Thoughts? R=jar Review URL: http://codereview.chromium.org/1829 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1891 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate the TimerManager by pulling its priority queue into MessageLoop. ↵darin@google.com2008-09-071-6/+186
| | | | | | | | | | This CL also eliminates TaskBase by creating a simple PendingTask struct that is allocated inline within a std::queue used to implement the queues in the MessageLoop class. R=jar Review URL: http://codereview.chromium.org/483 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1825 0039d316-1c4b-4281-b951-d872f2087c98
* Allow consumers of MessageLoop to specify the type of MessageLoop they want.darin@google.com2008-08-261-75/+149
| | | | | | | | | | | | | | | | This CL introduces a Type enum to MessageLoop, and I also created subclasses of MessageLoop corresponding to the non-default types: MessageLoopForIO and MessageLoopForUI. I moved all of the platform-specific MessageLoop APIs onto either MessageLoopForIO or MessageLoopForUI. MessageLoopForIO gets the Watcher API, and MessageLoopForUI gets the Observer and Dispatcher APIs. Under the hood, both are implemented in terms of MessagePumpWin, but that will change in a future CL. The Thread class is changed to allow the consumer to specify the Type of MessageLoop they want to have setup on the created thread. I re-organized message_loop_unittest.cc and timer_unittest.cc so that I could exercise all (or most) of the tests against each type of MessageLoop. Note: I know that "explicit MessageLoop(Type type = TYPE_DEFAULT);" is in violation to the style-guide's restriction against default arguments. I'm working on finding a decent solution to that problem. Please ignore this issue for now. The corresponding chrome/ changes are coming in a separate CL due to Reitveld data size limitations. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1362 0039d316-1c4b-4281-b951-d872f2087c98
* Use a more compact license header in source files.license.bot2008-08-241-28/+4
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
* Define MessagePumpDefault and use it to implement MessageLoop on non-Windowsdarin@google.com2008-08-191-9/+27
| | | | | | | | | | | | | | | | | platforms. This is actually just a first-step toward the real fix which is to use MessagePumpDefault on all platforms on non-UI and non-IO threads. This CL also fixes some GCC compilation errors. I renamed MessageLoopOwnable to TaskBase, which seems more appropriate since a MessageLoopOwnable has a next Task pointer and clearly is only meaningful in the context of Task. (I wonder why it is even a separate class, but that is another issue.) I had to make the next_task / set_next_task methods public since they are used by an inner class of MessageLoop. Perhaps those inner classes should be made into top-level classes, but that seemed like too much to change at this time. R=jar,mmentovai git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1045 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce MessagePump to represent the native message pump used to drive adarin@google.com2008-08-151-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MessageLoop. A MessageLoop now has a MessagePump. This will make it possible to port the MessagePump interface to other platforms as well as to use an IO completion port for our worker threads on Windows. Currently, there is only MessagePumpWin, which attempts to preserve the pre-existing behavior of the MessageLoop. API changes to MessageLoop: 1. MessageLoop::Quit means return from Run when the MessageLoop would otherwise wait for more work. 2. MessageLoop::Quit can no longer be called outside the context of an active Run call. So, things like this: MessageLoop::current()->Quit(); MessageLoop::current()->Run(); are now: MessageLoop::current()->RunAllPending(); 3. MessageLoop::Quit can no longer be called from other threads. This means that PostTask(..., new MessageLoop::QuitTask()) must be used explicitly to Quit across thread boundaries. 4. No protection is made to deal with nested MessageLoops involving watched objects or APCs. In fact, an assertion is added to flag such cases. This is a temporary measure until object watching and APC facilities are removed in favor of a MessagePump designed around an IO completion port. As part of this CL, I also changed the automation system to use an IPC::ChannelProxy instead of an IPC::Channel. This moves the automation IPC onto Chrome's IO thread where it belongs. I also fixed some abuses of RefCounted in the AutomationProvider class. It was deleting itself in some cases! This led to having to fix the ownership model for AutomationProvider, which explains the changes to AutomationProviderList and so on. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@928 0039d316-1c4b-4281-b951-d872f2087c98
* I removed a questionable use of Quit() on a message loopjar@google.com2008-08-141-3/+3
| | | | | | | | | | | in test (it was a redundant use of quit which was caught when I wrote code to detect this construct, which caused hangs in some race scenarios). r=darin git-svn-id: svn://svn.chromium.org/chrome/trunk/src@848 0039d316-1c4b-4281-b951-d872f2087c98
* Rollback message loop testjar@google.com2008-08-031-3/+3
| | | | | | TBR git-svn-id: svn://svn.chromium.org/chrome/trunk/src@299 0039d316-1c4b-4281-b951-d872f2087c98
* This is a test, and will rollback asap after a build/test cycle starts.jar@google.com2008-08-031-3/+3
| | | | | | | | | | I use a counter of MessageLoop::Quit() calls so that I can re-post "extra" calls when MessageLoop::Run() terminates. This assures that no quits are lost... but I'm not sure if some code abused the Quit() calls, and already posts many-too-many quits :-/. I want to see if the tree tests go red, and how the distributed reliability test responds. The test should already pass the basic unit_test and base_unittest, but I'm not sure what the rest of the UI tests etc will do. If I'm lucky, they'll be "less" flakey. ...but they may just go red all over :-( TBR git-svn-id: svn://svn.chromium.org/chrome/trunk/src@298 0039d316-1c4b-4281-b951-d872f2087c98
* Fix most issues when building base as a x64 target.maruel@google.com2008-07-301-0/+23
| | | | | | BUG=1282556 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@112 0039d316-1c4b-4281-b951-d872f2087c98
* Add base to the repository.initial.commit2008-07-261-0/+827
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-15 22:46:30 +0000