summaryrefslogtreecommitdiffstats
path: root/ipc/ipc_sync_channel.cc
Commit message (Collapse)AuthorAgeFilesLines
* Add MessageLoop::QuitNow and use it to terminate a sync IPC.darin@chromium.org2010-02-231-1/+1
| | | | | | | | | | | | | This is a test to observe the performance impact of this change. As such, I'm reverting r39518 as part of this change. R=jam BUG=36310 TEST=none Review URL: http://codereview.chromium.org/652089 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@39699 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Better handle oversized IPC messages" r37102jeremy@chromium.org2010-01-261-9/+0
| | | | git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37104 0039d316-1c4b-4281-b951-d872f2087c98
* Better handle oversized IPC messagesjeremy@chromium.org2010-01-261-0/+9
| | | | | | | | | | | | | | * Shoot down oversized messages on the sending side so we fail faster. * Add DCHECKs to identify oversized messages early. The real fix for the underlying bug is not to send oversized messages in the first place, but the current state of things is that it takes a long while for the renderer to crash. This change should speed the failure up a bit. BUG=26822 TEST=Chrome should continue to load web pages. Review URL: http://codereview.chromium.org/546047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37102 0039d316-1c4b-4281-b951-d872f2087c98
* Don't use any member variables when sending a sync call, since SyncChannel ↵jam@chromium.org2009-12-011-26/+27
| | | | | | | | | could be deleted. BUG=20364 Review URL: http://codereview.chromium.org/455011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33414 0039d316-1c4b-4281-b951-d872f2087c98
* Fix 64-bit warnings (for 64-bit Windows build)gregoryd@google.com2009-11-201-1/+1
| | | | | | | | BUG=28176 TEST=none Review URL: http://codereview.chromium.org/416003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32620 0039d316-1c4b-4281-b951-d872f2087c98
* First patch in making destructors of refcounted objects private.jam@chromium.org2009-11-051-3/+4
| | | | | | | BUG=26749 Review URL: http://codereview.chromium.org/360042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31136 0039d316-1c4b-4281-b951-d872f2087c98
* The send done event in the old send watcher can be NULL as it can be ↵ananta@chromium.org2009-10-141-1/+1
| | | | | | | | | | | | | | | signaled in a nested sync channel send scenario which yields control to the plugin before the quit task is processed. This is perfectly legit and we should not attempt to StopWatching the send done watcher as it crashes. I will work on a unit test for this in a subsequent CL. TBR=jam Review URL: http://codereview.chromium.org/279002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29000 0039d316-1c4b-4281-b951-d872f2087c98
* John, please review everything.ananta@chromium.org2009-10-141-6/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Split the IPC code into ipc/agl@chromium.org2009-07-221-0/+453
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This splits the ipc code from the common project. The 'common' project pulls in all of webkit, the v8 bindings, skia, googleurl, and a number of other projects which makes it very difficult to deal with especially for external projects wanting just to use some of Chromium's infrastructure. This puts the ipc code into its top-level ipc/ directory with a dependency only on base. The common project depends on the new ipc/ipc.gyp:ipc target so that all projects currently pulling common in to get the IPC code still have it available. This mostly follows agl's pre-gyp attempt to do this which was r13062. Known issues: - Currently a number of projects depend on chrome/chrome.gyp:common in order to use the IPC infrastructure. Rather than fixing all of these dependencies I have made common depend on ipc/ipc.gyp:ipc and added "ipc" to the include_rules section of DEPS so that checkdeps.py doesn't complain. Over time projects that need IPC should depend on the IPC project themselves and dependencies on common removed, although I don't think many projects that need IPC will be able to get away without common currently. - ipc/ipc_message_macros.h still has #include "chrome/common/..." inside of a ipc/ should not refer to files in chrome/... now. I'm not sure how to resolve this since it's really an IDE bug - the named pipe name (windows+linux) and the logging event name (all) + env variable (posix) refer explicitly to 'Chrome' which somewhat hurts the illusion of ipc/ being an independent library. I think this should be examined in a subsequent, much smaller patch. - I've eliminated the IPC.SendMsgCount counter since it was implemented in a way to create a dependency from ipc/ to chrome/common/chrome_counters. This is the same approach that r13062 took. http://codereview.chromium.org/155905 (Patch from James Robinson) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21342 0039d316-1c4b-4281-b951-d872f2087c98
* Revert "Move IPC code to ipc/"agl@chromium.org2009-04-031-453/+0
| | | | | | | This reverts commit r13062 which, unsurprisingly, broke the build. git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13063 0039d316-1c4b-4281-b951-d872f2087c98
* Move IPC code to ipc/agl@chromium.org2009-04-031-0/+453
(No review URL: Rietvelt couldn't cope) git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13062 0039d316-1c4b-4281-b951-d872f2087c98