summaryrefslogtreecommitdiffstats
path: root/base/message_loop.h
Commit message (Collapse)AuthorAgeFilesLines
* Simplify OneShotTimer and RepeatingTimer. Fix up all consumers.darin@google.com2008-08-281-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | Major changes: OneShotTimer and RepeatingTimer become template classes that no longer require a Task or a Timer object. They just use PostDelayedTask. Under the hood that still uses a Timer object. The API is much simpler for consumers as they now no longer need to worry about allocating a Task or managing the lifetime of the object pointer held by the Task. I added some new unit tests to timer_unittest.cc to cover the API. I preserved the old TimerManager / Timer API for now, but I plan to soon kill it. R=brettw BUG=1346553 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1502 0039d316-1c4b-4281-b951-d872f2087c98
* Disable this DCHECK since too many consumers expect to be able todarin@google.com2008-08-261-1/+3
| | | | | | | | | call this when there is no MessageLoop for the current thread. TBR=jabdelmalek git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1372 0039d316-1c4b-4281-b951-d872f2087c98
* Allow consumers of MessageLoop to specify the type of MessageLoop they want.darin@google.com2008-08-261-34/+102
| | | | | | | | | | | | | | | | 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
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-1/+1
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1122 0039d316-1c4b-4281-b951-d872f2087c98
* Revert. Failing unit tests.evanm@google.com2008-08-201-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1118 0039d316-1c4b-4281-b951-d872f2087c98
* TrackedObjects assumes you can use a "TLS slot" of -1 to indicate ↵evanm@google.com2008-08-201-1/+1
| | | | | | uninitialized. This isn't true for the pthread_key_t type, which is unsigned on Linux and reportedly a struct on Macs. This change modifies the Slot type to be a struct containing an "initialized" flag. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1113 0039d316-1c4b-4281-b951-d872f2087c98
* reland r1075 w/ tweak to fix test failuresdarin@google.com2008-08-201-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1084 0039d316-1c4b-4281-b951-d872f2087c98
* rollback r1075 to see if it helps resolve test failuresdarin@google.com2008-08-201-1/+1
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1078 0039d316-1c4b-4281-b951-d872f2087c98
* Eliminate TimerManager::GetCurrentDelay in favor of always referring to the ↵darin@google.com2008-08-201-1/+1
| | | | | | | | | | | fire time of the next timer. I changed the MessagePump API to refer to a delayed_work_time instead of a delay. I moved the ceil-based rounding code into the Window's implementations of WaitableEvent and MessagePump. R=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1075 0039d316-1c4b-4281-b951-d872f2087c98
* Take 2 at the new MessageLoop implementation.darin@google.com2008-08-161-303/+119
| | | | | | | | R=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@973 0039d316-1c4b-4281-b951-d872f2087c98
* rollback portions of r928 to test to see if it impacts perfdarin@google.com2008-08-151-118/+296
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@936 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce MessagePump to represent the native message pump used to drive adarin@google.com2008-08-151-295/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* git-svn-id: svn://svn.chromium.org/chrome/trunk/src@760 ↵darin@google.com2008-08-121-0/+5
| | | | 0039d316-1c4b-4281-b951-d872f2087c98
* git-svn-id: svn://svn.chromium.org/chrome/trunk/src@739 ↵darin@google.com2008-08-121-5/+0
| | | | 0039d316-1c4b-4281-b951-d872f2087c98
* Make timer.cc portable by factoring its Windows bits into MessageLoop.darin@google.com2008-08-121-0/+5
| | | | | | Please note that the goal of this CL is merely to move the Windowisms out of timer.cc and into message_loop.cc. Next up will be to refactor message_loop.cc so that the Windowisms are further isolated. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@734 0039d316-1c4b-4281-b951-d872f2087c98
* I came across this when looking at MessageLoop recently.sky@google.com2008-08-111-6/+0
| | | | | | | BUG=none TEST=none; this is just a doc change. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@678 0039d316-1c4b-4281-b951-d872f2087c98
* just some hopefully non-contentious stuff to get out of the way before doing ↵darin@google.com2008-08-061-40/+55
| | | | | | the real MessageLoop changes. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@459 0039d316-1c4b-4281-b951-d872f2087c98
* ObjectWatcher needs to know when the current thread's MessageLoop is being ↵darin@google.com2008-08-051-3/+26
| | | | | | destroyed. This might also be generically useful, so I added a new API on ML to observe when the ML is being destroyed. The notification is sent to observers just prior to ML::current() being modified to return NULL. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@407 0039d316-1c4b-4281-b951-d872f2087c98
* Rollback message loop testjar@google.com2008-08-031-5/+4
| | | | | | 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-4/+5
| | | | | | | | | | 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
* Call ResetBirthTime before dispatching the user's Task. Also, remove ↵darin@google.com2008-08-021-4/+0
| | | | | | | | PostSignaledTask since it won't be used. TBR=jar git-svn-id: svn://svn.chromium.org/chrome/trunk/src@289 0039d316-1c4b-4281-b951-d872f2087c98
* A new (private) interface is supplied that allows the object watcher (coding injar@google.com2008-08-011-0/+4
| | | | | | | | | | | | | | | | | | | | | proress by Darin) to Post the task (when the object is signaled) into a message loop. I also cleaned up the time-of-birth for tasks that sleep for a while before running (such as those held by the timer, or by passed to this new PostSignaledTask() interface. r=darin M base/tracked.cc M base/message_loop.h M base/message_loop.cc M base/tracked.h git-svn-id: svn://svn.chromium.org/chrome/trunk/src@262 0039d316-1c4b-4281-b951-d872f2087c98
* Support RanAllPending() rather than RunOnce(), and integrated into ↵jar@google.com2008-07-311-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | ipc_sync_channel. RunOnce() semantics were not sufficient to support the effort to pump messages in ipc_sync_channel, as ipc_sync_channel is not able to detect pending Tasks. This change list switches to RunAllPending() tasks, rather than just Running the items that avail themselves in one run of the loop. This is a very small mod of the existing code. I'm still trying to stay focused on the bug at hand, and minimize chances of unrelated regressions (we only modify IPC channel semantics). The slight semantic change (from original attempts to call Quit() externally and then Run()) is that we now terminate the message loop after also servicing the high-resolution timer tasks. bug=1291034 r=darin M base/message_loop.h M base/message_loop.cc M chrome/common/ipc_sync_channel.cc git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176 0039d316-1c4b-4281-b951-d872f2087c98
* (Re-landing of) Support RunOnce() in message loop.jar@google.com2008-07-301-8/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Deeply nested calls to MessageLoop::Run() were made, and a multitude of Quit() messages were handled at the most nested level. This left outer invocations hung, waiting for "their" kQuitMsg to arrive (but the the nested loop had already discarded them in its processing of pending messages before exit :-/ ). We now use a more controlled run of the message loop, which does not rely on kQuitMsg. This re-landing doesn't have the anti-hang assertion, which was breaking a lot of tests. bug=1291034 r=darin,mpcomplete M base/message_loop.h M base/message_loop.cc M chrome/common/ipc_sync_channel.cc git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130 0039d316-1c4b-4281-b951-d872f2087c98
* Rollback 109jar@google.com2008-07-301-21/+8
| | | | | | | | | | M base/message_loop.h M base/message_loop.cc M chrome/common/ipc_sync_channel.cc git-svn-id: svn://svn.chromium.org/chrome/trunk/src@110 0039d316-1c4b-4281-b951-d872f2087c98
* M base/message_loop.hjar@google.com2008-07-301-8/+21
| | | | | | | | M base/message_loop.cc M chrome/common/ipc_sync_channel.cc git-svn-id: svn://svn.chromium.org/chrome/trunk/src@109 0039d316-1c4b-4281-b951-d872f2087c98
* Do not use RecycleOrDelete since it is not ready for prime-time.darin@google.com2008-07-301-4/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@100 0039d316-1c4b-4281-b951-d872f2087c98
* Fix some issues when building with Visual Studio 2008.maruel@google.com2008-07-281-1/+0
| | | | | | | | | | | | | | Fixed projects that are set as "Application (.exe)" but that don't build an application. Converted then to "Utility". util_prebuild, V8Config and V8Bindings_prebuild. Fixed a template compilation error in message_loop.h Changed PROP_ENTRY to PROP_ENTRY_TYPE since the former is now deprecated. Everything still builds fine on VS2005. BUG=1290595 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44 0039d316-1c4b-4281-b951-d872f2087c98
* Add base to the repository.initial.commit2008-07-261-0/+611
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-17 13:35:36 +0000