Use mojo for Chrome Loading, Part 1

content/browser/loader/url_loader_factory_holder.cc

+// Copyright 2016 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/browser/loader/url_loader_factory_holder.h"
+
+#include <memory>
+
+#include "base/bind.h"
+#include "base/memory/ptr_util.h"
+#include "content/browser/loader/resource_dispatcher_host_impl.h"
+#include "content/browser/loader/resource_message_filter.h"
+#include "content/common/resource_request.h"
+#include "content/common/url_loader.mojom.h"
+#include "content/common/url_loader_factory.mojom.h"
+#include "content/public/browser/browser_thread.h"
+#include "mojo/public/cpp/bindings/binding.h"
+
+namespace content {
+
+namespace {
+
+// This class is an implementation of mojom::URLLoader which is a resource
+// loader interface with Mojo.
+class URLLoaderImpl final : public mojom::URLLoader {
+ public:
+  explicit URLLoaderImpl(mojo::InterfaceRequest<mojom::URLLoader> request)
+      : binding_(this, std::move(request)) {}
+  ~URLLoaderImpl() override {}
+
+  void FollowRedirect() override {}
+  void Cancel() override {}

[mmenke, 2016/06/13 20:56:58]

NOTREACHED() for both of these, and a TODO about hooking them up?  Hrm, with
this architecture, how can they reasonably be hooked up?  Should the
MojoAsyncResourceHandler actually be the URLLoader?  Not quite sure what that
would look like, in terms of the wiring.

[yhirano, 2016/07/12 10:49:11]

Ah, it's a good idea. Thank you.

+
+ private:
+  mojo::Binding<mojom::URLLoader> binding_;
+
+  DISALLOW_COPY_AND_ASSIGN(URLLoaderImpl);
+};
+
+}  // namespace
+
+// This class is an implementation of mojom::URLLoaderFactory that creates
+// a mojom::URLLoader.
+class URLLoaderFactoryHolder::URLLoaderFactoryImpl final
+    : public mojom::URLLoaderFactory {
+ public:
+  explicit URLLoaderFactoryImpl(
+      scoped_refptr<ResourceMessageFilter> resource_message_filter)
+      : resource_message_filter_(std::move(resource_message_filter)) {
+    DCHECK(resource_message_filter_);
+    DCHECK_CURRENTLY_ON(BrowserThread::UI);
+  }
+  ~URLLoaderFactoryImpl() override { DCHECK_CURRENTLY_ON(BrowserThread::IO); }
+
+  void CreateLoaderAndStart(mojom::URLLoaderRequest request,
+                            int32_t request_id,
+                            const ResourceRequest& url_request,
+                            mojom::URLLoaderClientPtr client) override {
+    DCHECK_CURRENTLY_ON(BrowserThread::IO);
+
+    std::unique_ptr<mojom::URLLoader> loader(
+        new URLLoaderImpl(std::move(request)));
+
+    // TODO(yhirano): Provide the right routing ID.
+    const int routing_id = 0;
+    ResourceDispatcherHostImpl* rdh = ResourceDispatcherHostImpl::Get();
+    rdh->OnRequestResourceWithMojo(routing_id, request_id, url_request,
+                                   std::move(loader), std::move(client),
+                                   resource_message_filter_.get());
+  }
+
+  void Bind(mojo::InterfaceRequest<mojom::URLLoaderFactory> request) {
+    DCHECK_CURRENTLY_ON(BrowserThread::IO);
+    binding_.reset(
+        new mojo::Binding<URLLoaderFactory>(this, std::move(request)));
+  }
+
+ private:
+  scoped_refptr<ResourceMessageFilter> resource_message_filter_;
+  std::unique_ptr<mojo::Binding<mojom::URLLoaderFactory>> binding_;
+
+  DISALLOW_COPY_AND_ASSIGN(URLLoaderFactoryImpl);
+};
+
+URLLoaderFactoryHolder::URLLoaderFactoryHolder(
+    scoped_refptr<ResourceMessageFilter> resource_message_filter,
+    mojo::InterfaceRequest<mojom::URLLoaderFactory> request)
+    : factory_(new URLLoaderFactoryImpl(resource_message_filter)) {

[mmenke, 2016/06/13 20:56:58]

Why is this cross-thread dongle necessary?  Can we just create the
URLLoaderFactory in  ResourceDispatcherHostImpl::OnInit, and destroy it in
ResourceDispatcherHostImpl::OnShutdown?  That ties its lifecycle directly to the
class it actually depends on.

Alternatively, could even make the RDHI implement URLLoaderFactory, and set
up/tear down the binding itself in those two methods.  Think that makes a lot
more sense, in the long term, particularly if we plan to have nothing call into
the RDH directly to create requests, and instead only provide the mojo
interface.

[kinuko, 2016/06/14 08:45:29]

While this sounds like a better direction I feel this will need relatively
bigger refactoring that could be possibly done later..?

We'll still need some tie between RPHI (and ResourceMessageFilter) to call
existing RDHI handily with access to storage stuff etc. Creating  this holder
with ResourceMessageFilter in RPHI seems to be reasonably simple to start with
to me.  (Just wondering, as you must have more solid design ideas around these
bits)

[yhirano, 2016/07/12 10:49:11]

I'm planning to create a URLLoaderFactory for a RenderFrameHost, so The lifetime
of URLLoaderFactory doesn't equal to RDHI.

+  DCHECK_CURRENTLY_ON(BrowserThread::UI);
+  // This |Unretained| is safe because ~URLLoaderFactoryHolder is the only
+  // function that posts a |factory_| deletion task to the IO thread and
+  // ~URLLoaderFactoryHolder is called on this thread.
+  BrowserThread::PostTask(
+      BrowserThread::IO, FROM_HERE,
+      base::Bind(&URLLoaderFactoryImpl::Bind, base::Unretained(factory_.get()),
+                 base::Passed(std::move(request))));
+}
+
+URLLoaderFactoryHolder::~URLLoaderFactoryHolder() {
+  DCHECK_CURRENTLY_ON(BrowserThread::UI);
+  BrowserThread::DeleteSoon(BrowserThread::IO, FROM_HERE, factory_.release());
+}
+
+}  // namespace content