| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
agl, please review changes to the waitable_event_watcher code.
Multiple sync channels if used in the same listener thread could result in calls completing in the
wrong context at times. This happens if there are nested calls on these sync channels, i.e
1. Call from client 1 on channel 1 to server 1. Message pumping is enabled for the corresponding message
2. Call from client 2 on channel 2 to server 2, Message pumping is enabled for the corresponding message
Now if a reply for 1 arrives, it should be queued until reply 2 arrives. This does not happen which
causes 2 to terminate prematurely leading to crashes, 1 waiting indefinitely at times, etc.
The fix for this issue is to maintain a local global stack for the send done event watcher object.
The global object is in the form of a TLS. This ensures that we only watch for completed events
on the outermost sync channel.
The changes in the Waitable event watcher object are to return the current delegate which is needed
to start watching the old send watcher once we are done and to ensure that the event member is set even
if it was already signaled when StartWatching was called.
I have added a unit test in ipc_tests for this case. I removed the old QueuedReply based unit tests as
they did not test the actual nested call case.
While debugging these issues I also found some issues in BrowserRenderProcessHost::OnChannelError where
it would delete a sync channel while it was in use. Based on a discussion with jam we decided to DeleteSoon
the sync channel pointer. However this broke some browser ui tests which relied on the timing of the OnChannelError notification.
We decided to leave the existing code as is for now. I removed the DCHECK on channel as it would fire repeatedly if the channel died
while multiple sync calls were waiting to complete leading to OnChannelError firing multiple times.
Bug=24427
Review URL: http://codereview.chromium.org/271033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@28967 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
|
| |
|
|
|
|
|
|
|
| |
(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
|
|
|
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
|
