| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
One of the big things is starting to move/declare ctors/dtors that derive from RefCounted<> to/in the implementation file.
(Saves 4 megabytes from libglue.a alone. 1 meg off libbrowser.a. Hundred of kilobyte savings in a large number of .a files; only libmedia.a grew and it's only 100k.)
BUG=none
TEST=compiles
Review URL: http://codereview.chromium.org/3452030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60863 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cannot be destroyed (pthread_cond_destroy) during a broadcast
(pthread_cond_broadcast). SyncWaiter::Fire now holds the lock until the
broadcast is complete. Given the lock ordering, this guarantees that the
condition variable cannot be destroyed until it is safe to do so. Holding
the lock through the broadcast is harmless, as pthread_cond_wait and
pthread_cond_timedwait will simply block (if needed) until able to take the
lock prior to returning.
Ownership of the lock and condition variable is moved to SyncWaiter for better
self-documentation. The only true functional change here, however, is the
duration that SyncWaiter::Fire holds the lock.
This bug caused hangs in optimized official release builds on the Mac when
DCHECKS were optimized away. The DCHECK optimization was initially covered in
bug 16512 r20497 and was backed out due to bug 16871 r20889. The optimization
changed the timings just enough that we wound up hitting this case. On the
Mac, pthread_cond_broadcast wound up blocking indefinitely (with a trashed
stack) when its condition variable was destroyed beneath it; this caused other
locks held by its thread to never be released, resulting in other threads
becoming deadlocked and made the bug particularly difficult to diagnose.
BUG=19710
TEST=Application works with no unexplained deadlocks, hanging, or crashing
base_unittests (specifically WaitableEvent*)
ipc_tests (especially IPCSyncChannelTest.ChattyServer, which would hang
previously on the Mac with DCHECKs optimized away)
Review URL: http://codereview.chromium.org/173059
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@23790 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
This reverts commit r12459 - it broke the world.
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@12462 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/18298
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8143 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/18122
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8138 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/16610
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8136 0039d316-1c4b-4281-b951-d872f2087c98
|
| |
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/18288
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@8128 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
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
|
