summaryrefslogtreecommitdiffstats
path: root/base/object_watcher_unittest.cc
Commit message (Collapse)AuthorAgeFilesLines
* Style cleanup in preparation for auto-linting base/.erg@google.com2010-01-261-1/+1
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/552004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37164 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes CRLF and trailing white spaces.maruel@chromium.org2009-03-051-2/+2
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10982 0039d316-1c4b-4281-b951-d872f2087c98
* NO CODE CHANGE (except one global std::wstring changed to const wchar_t* ↵maruel@chromium.org2009-03-031-5/+5
| | | | | | | | | | | const per style compliance). Preliminary work to enforce new PRESUBMIT.py rules: - <=80 cols - no trailing whitespaces - svn:eol-style=LF git-svn-id: svn://svn.chromium.org/chrome/trunk/src@10791 0039d316-1c4b-4281-b951-d872f2087c98
* Make IPC::SyncChannel not duplicate the underlying MessageLoop ↵jam@chromium.org2008-10-241-0/+3
| | | | | | | | implementation by pumping messages on its own. This fixes the problem of windowless plugins not painting on right click, and generally makes this class almost ported, other than using a generic version of events/locks.Through this change I've also cleaned up the class and hopefully made it more understandable. Review URL: http://codereview.chromium.org/8001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@3934 0039d316-1c4b-4281-b951-d872f2087c98
* Run ObjectWatcher unit tests against all types of message loops.darin@google.com2008-09-241-10/+34
| | | | | | | | R=jar Review URL: http://codereview.chromium.org/4245 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@2570 0039d316-1c4b-4281-b951-d872f2087c98
* Allow consumers of MessageLoop to specify the type of MessageLoop they want.darin@google.com2008-08-261-20/+12
| | | | | | | | | | | | | | | | 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
* ObjectWatcher needs to know when the current thread's MessageLoop is being ↵darin@google.com2008-08-051-0/+33
| | | | | | 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
* Revise the ObjectWatcher API to be one-to-one with the object being watched. ↵darin@google.com2008-08-041-82/+30
| | | | | | | | | | | | This greatly simplifies the implementation and API. Now consumers can use ObjectWatcher as a "smart pointer" class, which automatically cleans-up after itself when it goes out of scope. I also switched away from the Task based API to one that is more compatible with MessageLoop::WatchObject. That allows me to make minimal changes to existing code, and it also means that consumers do not have to allocate Task objects to use this API. In this CL, I included changes to make a couple consumers use ObjectWatcher instead of ML::WatchObject. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@322 0039d316-1c4b-4281-b951-d872f2087c98
* A helper class for calling RegisterWaitForSingleObject with the objective of ↵darin@google.com2008-08-011-0/+167
finding out when objects get signaled. The API is pretty simple: - consumer can associate a Task with a HANDLE via AddWatch method - when the HANDLE is signaled, we run the Task on the thread that called AddWatch - the consumer can call CancelWatch to abort the watch - a watch is one-shot: after the object is signaled, the consumer has to call AddWatch again to wait a second time - if the ObjectWatcher instance is destroyed, it cancels all associated watches. Implementation details: - Uses RegisterWaitForSingleObject to run a function on the wait thread. This avoids extra thread marshaling to a worker thread. - Uses a Task to get back onto the origin thread. This is possible due to the UnregisterWaitEx(INVALID_HANDLE_VALUE) call. - Once on the origin thread, runs the consumer's Task directly. This is the first part of changes I want to make to MessageLoop::WatchObject. For now, I have not made any changes to existing code. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@259 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2024-09-13 06:19:56 +0000