forked from chromium/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Mojo: Make some attempts towards fixing remote message pipe closure.
It's not quite right yet (I still need to fix how they get started -- i.e., attached and run -- since that races in a poor way with how they get closed), but I think I'm getting closer. There's an intentional cycle of ref-counted objects, between the ProxyMessagePipeEndpoint and the Channel, which needs to be broken when one of the (real) endpoints of the message pipe is closed. The picture is: LocalMPE-ProxyMPE-Channel <-----> Channel-ProxyMPE-LocalMPE When a LocalMessagePipeEndpoint is closed, ultimately the other LocalMessagePipeEndpoint needs to be informed ("OnPeerClosed"), and the two ProxyMessagePipeEndpoints can be torn down. There are many difficulties, however. First, while a ProxyMessagePipeEndpoint may be torn down, its entry (with its local ID) may not be removed from the Channel until it's known that the other side will not send messages to that ID (because you can't re-use that ID until then). Basically, this amounts to notifying the other side and receiving an ack. (We can mark the entry in the Channel with a suitable "zombie" state to handle this.) Second, both LocalMessagePipeEndpoints may be closed "simultaneously" -- resulting in the removal notification messages "crossing paths". Of course, once you receive a removal notification for a given ID, you know the other side will not send any more messages to that ID. So, there's no need to send an ack in that case. Now, there are lock order issues, so that removal of an ID from a channel (upon receiving a removal message) races with the LocalMessagePipeEndpoint (on the "local" side) being closed, so you have to handle that. Then there are races with the ProxyMessagePipeEndpoint being attached and run (and possibly receiving a removal message). (This CL doesn't address all those issues.) Finally, note that sometimes you have to keep the ProxyMessagePipeEndpoint alive past "OnPeerClose". E.g., it's valid for you to write a whole bunch of messages to a MessagePipe endpoint, and then immediately close it. The ProxyMessagePipeEndpoint must stay alive until it's been attached/run and sent out all those messages (and a remove message). R=darin@chromium.org BUG=360081 Review URL: https://codereview.chromium.org/240133005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@264716 0039d316-1c4b-4281-b951-d872f2087c98
- Loading branch information
viettrungluu@chromium.org
committed
Apr 18, 2014
1 parent
23761b9
commit 3e8f1f0
Showing
15 changed files
with
391 additions
and
132 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.