Move Mojo channel initialization closer to IPC::Channel setup

content/browser/renderer_host/render_process_host_impl.h

 // Copyright (c) 2012 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 CONTENT_BROWSER_RENDERER_HOST_BROWSER_RENDER_PROCESS_HOST_IMPL_H_
 #define CONTENT_BROWSER_RENDERER_HOST_BROWSER_RENDER_PROCESS_HOST_IMPL_H_
 
 #include <map>
 #include <queue>
 #include <string>
 
 #include "base/memory/scoped_ptr.h"
 #include "base/observer_list.h"
 #include "base/process/process.h"
 #include "base/timer/timer.h"
 #include "content/browser/child_process_launcher.h"
 #include "content/browser/geolocation/geolocation_dispatcher_host.h"
 #include "content/browser/power_monitor_message_broadcaster.h"
 #include "content/common/content_export.h"
+#include "content/common/render_process.mojom.h"
 #include "content/public/browser/gpu_data_manager_observer.h"
 #include "content/public/browser/render_process_host.h"
 #include "ipc/ipc_channel_proxy.h"
 #include "ipc/ipc_platform_file.h"
-#include "mojo/public/cpp/system/core.h"
+#include "mojo/embedder/scoped_platform_handle.h"
+#include "mojo/public/cpp/bindings/remote_ptr.h"
+#include "mojo/public/interfaces/shell/shell.mojom.h"
 #include "ui/surface/transport_dib.h"
 
 struct ViewHostMsg_CompositorSurfaceBuffersSwapped_Params;
 
 namespace base {
 class CommandLine;
 class MessageLoop;
 }
 
 namespace gfx {
 class Size;
 }
 
 namespace content {
 class AudioRendererHost;
 class BrowserDemuxerAndroid;
 class GeolocationDispatcherHost;
 class GpuMessageFilter;
 class MessagePortMessageFilter;
+class MojoApplicationHost;
 class PeerConnectionTrackerHost;
 class RendererMainThread;
 class RenderProcessHostMojoImpl;
 class RenderWidgetHelper;
 class RenderWidgetHost;
 class RenderWidgetHostImpl;
 class RenderWidgetHostViewFrameSubscriber;
 class ScreenOrientationDispatcherHost;
 class StoragePartition;
 class StoragePartitionImpl;
@@ skipping 10 matching lines @@
 // This object communicates back and forth with the RenderProcess object
 // running in the renderer process. Each RenderProcessHost and RenderProcess
 // keeps a list of RenderView (renderer) and WebContentsImpl (browser) which
 // are correlated with IDs. This way, the Views and the corresponding ViewHosts
 // communicate through the two process objects.
 //
 // A RenderProcessHost is also associated with one and only one
 // StoragePartition.  This allows us to implement strong storage isolation
 // because all the IPCs from the RenderViews (renderer) will only ever be able
 // to access the partition they are assigned to.
 class CONTENT_EXPORT RenderProcessHostImpl

[DaveMoore, 2014/04/16 23:08:36]

This seems bad. You have FooImpl, IFoo and Foo all in the same place. I think
the IRenderProcessHost needs to be more descriptive about exactly what part of
the interface it's declaring.

[darin (slow to review), 2014/04/16 23:26:04]

Yeah, I wanted to see what this would feel like. Do you have any suggestions on
alternate names?

The concerns I have:

1- I'm not a big fan of adding "Mojo" into the name as that seems like something
we shouldn't have to think about. These are just interfaces to be implemented.

2- While this interface currently has very few methods, I expect it to grow to
have all of the methods that represent the "render process host" from the point
of view of the "render process". Given that, the name should probably include
the term "RenderProcessHost" (and "RenderProcess" for the other end).

[DaveMoore, 2014/04/17 17:56:09]

So what will determine what's in the new interface as opposed to the old one? At
the end will the existing RenderProcessHost interface go away?

On 2014/04/16 23:26:04, darin wrote:

[koz (OOO until 15th September), 2014/04/22 07:09:59]

It's true that the mojo interfaces are just regular interfaces, but they have a
specific use in mind, that is, to receive messages from a mojo peer, which in
practice makes them quite special (they use special mojo types, can be invoked
cross-process and cross-privilege barrier...) For this reason IFoo and Foo are
semantically different, so it makes sense to distinguish them.

I think FooMojo reads a bit funny, because to me it looks like the Mojo
implementation of Foo. IFoo makes sense to me, but I think it's perhaps too
general because the I prefix typically just says it's an interface, not a
special "between-peer", mojo-ey interface.

How about mojom::Foo? I find having #include "foo.mojom.h" instead of #include
"foo.h" very useful, and I think it would be equally helpful to be able to see
which interfaces are mojo ones just by their name. Using a namespace instead of
a Mojom prefix or suffix has the benefit that we don't have to mangle the names
we use in .mojom files.

-    : public RenderProcessHost,
+    : public IRenderProcessHost,
+      public RenderProcessHost,
       public ChildProcessLauncher::Client,
       public GpuDataManagerObserver {
  public:
   RenderProcessHostImpl(BrowserContext* browser_context,
                         StoragePartitionImpl* storage_partition_impl,
                         bool supports_browser_plugin,
                         bool is_guest);
   virtual ~RenderProcessHostImpl();
 
   // RenderProcessHost implementation (public portion).
@@ skipping 169 matching lines @@
 #endif
 
   // The count of currently swapped out but pending RenderViews.  We have
   // started to swap these in, so the renderer process should not exit if
   // this count is non-zero.
   int32 pending_views_;
 
  private:
   friend class VisitRelayingRenderProcessHost;
 
+  void InitializeMojo();
+
   // Creates and adds the IO thread message filters.
   void CreateMessageFilters();
 
   // Control message handlers.
   void OnShutdownRequest();
   void OnDumpHandlesDone();
   void SuddenTerminationChanged(bool enabled);
   void OnUserMetricsRecordAction(const std::string& action);
   void OnSavedPageAsMHTML(int job_id, int64 mhtml_file_size);
 
@@ skipping 19 matching lines @@
   void ProcessDied(bool already_dead);
 
   virtual void OnGpuSwitching() OVERRIDE;
 
 #if defined(ENABLE_WEBRTC)
   // Sends |file_for_transit| to the render process.
   void SendAecDumpFileToRenderer(IPC::PlatformFileForTransit file_for_transit);
   void SendDisableAecDumpToRenderer();
 #endif
 
+  scoped_ptr<MojoApplicationHost> mojo_application_host_;
+  mojo::RemotePtr<IRenderProcess> render_process_;
+
   // The registered IPC listener objects. When this list is empty, we should
   // delete ourselves.
   IDMap<IPC::Listener> listeners_;
 
   // The count of currently visible widgets.  Since the host can be a container
   // for multiple widgets, it uses this count to determine when it should be
   // backgrounded.
   int32 visible_widgets_;
 
   // Does this process have backgrounded priority.
@@ skipping 109 matching lines @@
 #endif
 
   // Message filter and dispatcher for screen orientation.
   ScreenOrientationDispatcherHost* screen_orientation_dispatcher_host_;
 
   int worker_ref_count_;
 
   // Records the time when the process starts surviving for workers for UMA.
   base::TimeTicks survive_for_worker_start_time_;
 
-  scoped_ptr<RenderProcessHostMojoImpl> render_process_host_mojo_;
-
   base::WeakPtrFactory<RenderProcessHostImpl> weak_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(RenderProcessHostImpl);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_RENDERER_HOST_BROWSER_RENDER_PROCESS_HOST_IMPL_H_