summaryrefslogtreecommitdiffstats
path: root/base/waitable_event_watcher.h
Commit message (Collapse)AuthorAgeFilesLines
* POSIX: allow WaitableEvents to be deleted while watching them.agl@chromium.org2009-03-261-1/+6
| | | | | | | | | | | | | | | | | | | On Windows, one can close a HANDLE which is currently being waited on. The MSDN documentation says that the resulting behaviour is 'undefined', but it doesn't crash. Currently, on POSIX, one couldn't use WaitableEventWatcher to watch an event which gets deleted. This mismatch has bitten us several times now. This patch allows WaitableEvents to be deleted while a WaitableEventWatcher is still watching them. It applies only to watchers, the usual Wait() and WaitMany() calls still require that all their target be valid until the end of the call. http://crbug.com/8809 Review URL: http://codereview.chromium.org/53026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12576 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "POSIX: allow WaitableEvents to be deleted while watching them."agl@chromium.org2009-03-251-5/+1
| | | | | | | This reverts commit r12459 - it broke the world. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12462 0039d316-1c4b-4281-b951-d872f2087c98
* POSIX: allow WaitableEvents to be deleted while watching them.agl@chromium.org2009-03-251-1/+5
| | | | | | | | | | | | | | | | | | | On Windows, one can close a HANDLE which is currently being waited on. The MSDN documentation says that the resulting behaviour is 'undefined', but it doesn't crash. Currently, on POSIX, one couldn't use WaitableEventWatcher to watch an event which gets deleted. This mismatch has bitten us several times now. This patch allows WaitableEvents to be deleted while a WaitableEventWatcher is still watching them. It applies only to watchers, the usual Wait() and WaitMany() calls still require that all their target be valid until the end of the call. http://crbug.com/8809 Review URL: http://codereview.chromium.org/53026 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12459 0039d316-1c4b-4281-b951-d872f2087c98
* I let a tab slip into the code; remove it.agl@chromium.org2009-02-061-1/+1
| | | | | | | | | (I blame Visual Studio) Review URL: http://codereview.chromium.org/21131 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9324 0039d316-1c4b-4281-b951-d872f2087c98
* WaitableEvent is the replacement for Windows events. Previously in the code, ↵agl@chromium.org2009-01-151-0/+148
a HANDLE from CreateEvent was used for signaling, both within a process and across processes. WaitableEvent is the cross platform replacement for this. To convert: * HANDLE -> base::WaitableEvent* * ScopedHandle -> scoped_ptr<base::WaitableEvent> * CreateEvent -> new base::WaitableEvent * SetEvent -> base::WaitableEvent::Signal * ResetEvent -> base::WaitableEvent::Reset * ObjectWatcher -> base::WaitableEventWatcher * WaitForMultipleObjects -> static base::WaitableEvent::WaitMany ObjectWatcher remains for Windows specific code. WaitableEventWatcher has an identical interface save, * It uses WaitableEvents, not HANDLEs * It returns void from StartWatching and StopWatcher, rather than errors. System internal errors are fatal to the address space IMPORTANT: There are semantic differences between the different platforms. WaitableEvents on Windows are implemented on top of events. Windows events work across process and this is used mostly for modal dialog support. Windows events can be duplicated with DuplicateHandle. On other platforms, WaitableEvent works only within a single process. In the future we shall have to replace the current uses of cross-process events with IPCs. BEWARE: HANDLE, on Windows, is a void *. Since any pointer type coerces to void *, you can pass a WaitableEvent * where a HANDLE is expected without any build-time errors. Review URL: http://codereview.chromium.org/16554 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8126 0039d316-1c4b-4281-b951-d872f2087c98