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

mojo/system/message_pipe_dispatcher.h

Index: mojo/system/message_pipe_dispatcher.h
diff --git a/mojo/system/message_pipe_dispatcher.h b/mojo/system/message_pipe_dispatcher.h
index 1bfabc7e559f1263a2fd19b56fc0ba9b86e0f1a9..c0e6d2cfa41fced8c39e90134477e86294b70b5c 100644
--- a/mojo/system/message_pipe_dispatcher.h
+++ b/mojo/system/message_pipe_dispatcher.h
@@ -25,6 +25,15 @@ class MOJO_SYSTEM_IMPL_EXPORT MessagePipeDispatcher : public Dispatcher {
   // Must be called before any other methods. (This method is not thread-safe.)
   void Init(scoped_refptr<MessagePipe> message_pipe, unsigned port);
 
+  // Gets a dumb pointer to |message_pipe_|. This must be called under the
+  // |Dispatcher| lock. Note that it returns a dumb pointer. (This is okay,
+  // since the lock is held, and you're being careful, right?) This is needed
+  // when sending handles across processes, where nontrivial, invasive work
+  // needs to be done.

[DaveMoore, 2014/02/03 20:01:15]

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:11]

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).

+  MessagePipe* GetMessagePipeNoLock() const;
+  // Similarly for the port.
+  unsigned GetPortNoLock() const;
+
   virtual Type GetType() OVERRIDE;
 
  private: