diff options
author | darin@google.com <darin@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-01 21:04:03 +0000 |
---|---|---|
committer | darin@google.com <darin@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2008-08-01 21:04:03 +0000 |
commit | 51e48979a575e36f654ed277cd985ba44b6e3109 (patch) | |
tree | 4f5cd85579f15905d56da39ad02f4361ae3ce9ed /chrome/app | |
parent | 0307076af6164e2fcc2346a5af35ad610b9aa9e8 (diff) | |
download | chromium_src-51e48979a575e36f654ed277cd985ba44b6e3109.zip chromium_src-51e48979a575e36f654ed277cd985ba44b6e3109.tar.gz chromium_src-51e48979a575e36f654ed277cd985ba44b6e3109.tar.bz2 |
A helper class for calling RegisterWaitForSingleObject with the objective of 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
Diffstat (limited to 'chrome/app')
0 files changed, 0 insertions, 0 deletions