Hook up content/renderer to the PPAPI host.

content/renderer/pepper/pepper_in_process_resource_creation.cc

Index: content/renderer/pepper/pepper_in_process_resource_creation.cc
diff --git a/content/renderer/pepper/pepper_in_process_resource_creation.cc b/content/renderer/pepper/pepper_in_process_resource_creation.cc
new file mode 100644
index 0000000000000000000000000000000000000000..0f41ebed4755e892389e2a57e115cd014cceffe3
--- /dev/null
+++ b/content/renderer/pepper/pepper_in_process_resource_creation.cc
@@ -0,0 +1,104 @@
+// 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.
+
+#include "content/renderer/pepper/pepper_in_process_resource_creation.h"
+
+#include "content/renderer/pepper/content_renderer_pepper_host_factory.h"
+#include "ipc/ipc_message.h"
+#include "ipc/ipc_message_macros.h"
+#include "ppapi/host/ppapi_host.h"
+#include "ppapi/proxy/ppapi_messages.h"
+#include "ppapi/shared_impl/ppapi_globals.h"
+#include "ppapi/shared_impl/resource_tracker.h"
+
+// Note that the code in the creation functions in this file should generall be

[dmichael (off chromium), 2012/07/02 19:34:57]

generall->generally

+// the same as that in pepper/proxy/resource_creation_proxy.cc. See

[dmichael (off chromium), 2012/07/02 19:34:57]

pepper->ppapi?

+// pepper_in_process_resource_creation.h for what this file is for.
+
+namespace content {
+
+class PepperInProcessResourceCreation::PluginToHostRouter
+    : public IPC::Sender {
+ public:
+  PluginToHostRouter(RenderViewImpl* render_view,
+                     IPC::Sender* host_to_plugin_sender);
+  virtual ~PluginToHostRouter() {}
+
+  // Sender implementation.
+  virtual bool Send(IPC::Message* msg) OVERRIDE;
+
+ private:
+  ContentRendererPepperHostFactory factory_;
+  ppapi::host::PpapiHost host_;
+};
+
+PepperInProcessResourceCreation::PluginToHostRouter::PluginToHostRouter(
+    RenderViewImpl* render_view,
+    IPC::Sender* host_to_plugin_sender)
+    : factory_(render_view),
+      host_(host_to_plugin_sender, &factory_) {
+}
+
+bool PepperInProcessResourceCreation::PluginToHostRouter::Send(
+    IPC::Message* msg) {
+  scoped_ptr<IPC::Message> msg_deletor(msg);
+  return host_.OnMessageReceived(*msg);

[dmichael (off chromium), 2012/07/02 19:34:57]

Are there any cases where the proxy code assumes asynchronous messages?
Something to watch out for. As-is, it seems like if the proxy tries to do an
async request/reply currently, this will cause synchronous behavior and a nested
upcall while the plugin's Send is still on the stack. You might have to check if
the message is asynchronous, and if so post a task.

[brettw, 2012/07/03 16:52:54]

You're right, I should probably do this asynchronously. I did it in both
directions.

[dmichael (off chromium), 2012/07/03 17:08:52]

But now I think it won't work with synchronous messages. I think you have to
check which kind it is, right? I'm guessing you can just call directly for sync
messages...  if not, we can fix it later.

[brettw, 2012/07/03 17:22:53]

There are no synchronous resource messages (everything is nested in one of the
Call and Reply messages which are async). When we get to filtered input events,
we'll have to add a different type of message and I'm going to worry about that
later.

[dmichael (off chromium), 2012/07/03 17:30:16]

I'm not sure how it's going to support stuff like PPB_Buffer_Dev (at least in
its current form) with purely asynchronous messages...  e.g.:
PP_Resource buffer = buffer_if->Create(instance, 1024);
if (buffer)
  void* bytes = buffer_if->Map(buffer);

...but I'm willing to let you figure that stuff out later.

+}
+
+// HostToPluginRouter ---------------------------------------------------------
+
+class PepperInProcessResourceCreation::HostToPluginRouter
+    : public IPC::Sender {
+ public:
+  HostToPluginRouter() {}
+  virtual ~HostToPluginRouter() {}
+
+  // Sender implementation.
+  virtual bool Send(IPC::Message* msg) OVERRIDE;
+
+ private:
+  void OnMsgResourceReply(
+      const ppapi::proxy::ResourceMessageReplyParams& reply_params,
+      const IPC::Message& nested_msg);
+};
+
+bool PepperInProcessResourceCreation::HostToPluginRouter::Send(
+    IPC::Message* msg) {
+  scoped_ptr<IPC::Message> msg_deletor(msg);
+  IPC_BEGIN_MESSAGE_MAP(HostToPluginRouter, *msg)

[dmichael (off chromium), 2012/07/02 19:34:57]

Having this MESSAGE_MAP stuff in a Send is weird enough it might warrant a
comment here. I guess it's because you can't depend on whatever Listener class
you're going to have in ppapi/proxy that presumably will do pretty much what
OnMsgResourceReply below does?

Might you be able to have something in ppapi/shared_impl that does the
dispatching to call OnReplyReceived on the right Resource, so you don't have to
have that in 2 places? (Doesn't have to be this CL).

[brettw, 2012/07/03 16:52:54]

The while point of shared_impl is to be shared between the impl and the proxy,
and one of the main goals here is to make that unnecessary. So I think
shared_impl should go away. I think a lookup and a dispatch isn't so bad to
duplicate.

[dmichael (off chromium), 2012/07/03 17:08:52]

Yeah, it's pretty short now. I was afraid of whether it might get more
complicated, but it's certainly fine for now.

+    IPC_MESSAGE_HANDLER(PpapiPluginMsg_ResourceReply, OnMsgResourceReply)
+    IPC_MESSAGE_UNHANDLED(return false);
+  IPC_END_MESSAGE_MAP()
+  return true;
+}
+
+void PepperInProcessResourceCreation::HostToPluginRouter::OnMsgResourceReply(
+    const ppapi::proxy::ResourceMessageReplyParams& reply_params,
+    const IPC::Message& nested_msg) {
+  ppapi::Resource* resource =
+      ppapi::PpapiGlobals::Get()->GetResourceTracker()->GetResource(
+          reply_params.pp_resource());
+  if (!resource) {

[dmichael (off chromium), 2012/07/02 19:34:57]

Are we sure this can't happen? I guess right now, with the in-process case being
always synchronous, it should be safe. But I don't think that will hold if you
make it behave asynchronously (as you might need to).

Or are you doing something to bump the ref on a resource while it has a response
pending from the host?

[brettw, 2012/07/03 16:52:54]

Good point, I removed the assert & added a comment.

+    NOTREACHED();
+    return;
+  }
+  resource->OnReplyReceived(reply_params.sequence(), reply_params.result(),
+                            nested_msg);
+}
+
+// PepperInProcessResourceCreation --------------------------------------------
+
+PepperInProcessResourceCreation::PepperInProcessResourceCreation(
+    RenderViewImpl* render_view,
+    webkit::ppapi::PluginInstance* instance)
+    : ResourceCreationImpl(instance),
+      host_to_plugin_router_(new HostToPluginRouter),
+      plugin_to_host_router_(
+          new PluginToHostRouter(render_view, host_to_plugin_router_.get())) {
+}
+
+PepperInProcessResourceCreation::~PepperInProcessResourceCreation() {
+}
+
+}  // namespace content