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

mojo/system/message_pipe_dispatcher.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef MOJO_SYSTEM_MESSAGE_PIPE_DISPATCHER_H_
 #define MOJO_SYSTEM_MESSAGE_PIPE_DISPATCHER_H_
 
 #include "base/basictypes.h"
 #include "base/compiler_specific.h"
 #include "base/memory/ref_counted.h"
 #include "mojo/system/dispatcher.h"
 #include "mojo/system/system_impl_export.h"
 
 namespace mojo {
 namespace system {
 
 class MessagePipe;
 
 // This is the |Dispatcher| implementation for message pipes (created by the
 // Mojo primitive |MojoCreateMessagePipe()|). This class is thread-safe.
 class MOJO_SYSTEM_IMPL_EXPORT MessagePipeDispatcher : public Dispatcher {
  public:
   MessagePipeDispatcher();
 
   // 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:
   friend class base::RefCountedThreadSafe<MessagePipeDispatcher>;
   virtual ~MessagePipeDispatcher();
 
   // |Dispatcher| implementation/overrides:
   virtual void CancelAllWaitersNoLock() OVERRIDE;
   virtual MojoResult CloseImplNoLock() OVERRIDE;
   virtual MojoResult WriteMessageImplNoLock(
@@ skipping 16 matching lines @@
   scoped_refptr<MessagePipe> message_pipe_;  // This will be null if closed.
   unsigned port_;
 
   DISALLOW_COPY_AND_ASSIGN(MessagePipeDispatcher);
 };
 
 }  // namespace system
 }  // namespace mojo
 
 #endif  // MOJO_SYSTEM_MESSAGE_PIPE_DISPATCHER_H_