Mojo: More work towards sending message pipe handles over remote message pipes.

Mojo: More work towards sending message pipe handles over remote message pipes.

ProxyMessagePipeEndpoint::EnqueueMessage() needs to look at each handle
(i.e., dispatcher) and decide what to do.

This CL doesn't actually do anything yet exactly. I also need to check
(at a higher level) that we're not sending the peer handle over a given
handle, hence I'm splitting out this part now (since that work will
touch on the same things as this).

R=davemoore@chromium.org

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=248580

[DaveMoore, 2014-02-03 20:01:14]

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe.h
File mojo/system/message_pipe.h (right):

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe.h#n...
mojo/system/message_pipe.h:81: // another message pipe.
What is used?

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe_dis...
File mojo/system/message_pipe_dispatcher.h (right):

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe_dis...
mojo/system/message_pipe_dispatcher.h:32: // needs to be done.
Could this functionality be expressed through a separate interface that's
declared as a friend to the class that will use it? Comments != strong typing.

[viettrungluu, 2014-02-03 20:09:10]

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe.h
File mojo/system/message_pipe.h (right):

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe.h#n...
mojo/system/message_pipe.h:81: // another message pipe.
On 2014/02/03 20:01:15, DaveMoore wrote:
> What is used?

Oops (stale comment), deleted.

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe_dis...
File mojo/system/message_pipe_dispatcher.h (right):

https://codereview.chromium.org/145483005/diff/1/mojo/system/message_pipe_dis...
mojo/system/message_pipe_dispatcher.h:32: // needs to be done.
On 2014/02/03 20:01:15, DaveMoore wrote:
> Could this functionality be expressed through a separate interface that's
> declared as a friend to the class that will use it? Comments != strong typing.

I considered that, but friends get access to everything, which is no better (and
probably worse). Also, it spreads "knowledge" in the wrong direction -- suddenly
this class "knows" about things higher up in the food chain -- which is another
kind of fragility.

(There are hacks that would allow me to grant exactly the level of access that I
want, but it's overkill.)

It's fairly harmless to call these, with the proviso that they should be called
under lock (this is asserted, though it'd be even better if we had google3-style
lock annotations that can be statically analyzed).

[DaveMoore, 2014-02-03 21:39:15]

lgtm

[viettrungluu, 2014-02-03 21:42:40]

Committed patchset #3 manually as r248580 (presubmit successful).