Implement browser-side host resolver Mojo service.

net/dns/host_resolver_service_impl.h

+// Copyright 2015 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 NET_DNS_HOST_RESOLVER_SERVICE_IMPL_H_
+#define NET_DNS_HOST_RESOLVER_SERVICE_IMPL_H_
+
+#include <set>
+
+#include "base/macros.h"
+#include "base/threading/thread_checker.h"
+#include "net/interfaces/host_resolver_service.mojom.h"
+
+namespace net {
+
+class HostResolver;
+
+// This is the implementation of the HostResolverService Mojo interface.
+// Inbound Mojo requests are sent to the HostResolver passed into the
+// constructor. When destroyed, any outstanding resolver requests are cancelled.
+// If a request's HostResolverRequestClient is shut down, the associated
+// resolver request is cancelled.
+class HostResolverServiceImpl

[eroman, 2015/02/05 19:51:11]

I am not excited about the naming. "Service" is already a term used throughout
network stack, including for instance "ProxyService".

I would be happier if "Mojo" appeared somewhere in the name, as in MojoService
to make it clearer what these are.

(there may be an underlying net service, and then they may also be a MojoService
that wraps it).

[Anand Mistry (off Chromium), 2015/02/06 06:32:40]

https://memegen.googleplex.com/14366727
https://memegen.googleplex.com/5826145141391360
https://memegen.googleplex.com/6156198185271296

On a more serious note, Sam and I have come up with the following naming scheme:
- Mojo interfaces are just named HostResolver and ProxyResolver (no Service).
The rationale being that these are in separate namespaces and it's ok to clash.
On the flip side, there's no Mojo in the name, but I think that's implicit from
being in the net::interfaces namespace.
- The clients wrappers would be called HostResolverMojo and ProxyResolverMojo
(implementing the HostResolver and ProxyResolver interfaces respectively). This
fits with the existing convention for ProxyResolver, who's implementations
include ProxyResolverMac, ProxyReoslverV8, ProxyResolverV8Tracing, etc.
- The implementations of these interfaces should be called MojoHostResolverImpl
and MojoProxyResolverImpl. Mojo being somewhere in the name, and this scheme has
no potential clashes. We've ruled out HostResolverMojoImpl and
HostResolverImplMojo since these can easily be confused with the client
wrappers.

+    : public mojo::InterfaceImpl<interfaces::HostResolverService> {
+ public:
+  explicit HostResolverServiceImpl(HostResolver* resolver);

[eroman, 2015/02/05 19:51:11]

Please describe the lifetime expectations for |resovler|

[Anand Mistry (off Chromium), 2015/02/06 06:32:41]

Done.

+  ~HostResolverServiceImpl() override;
+
+  // Returns the number of outstanding requests.
+  // For testing only.
+  size_t OutstandingRequestsForTesting();
+
+ private:
+  class Job;
+
+  // Removes |job| from the set of pending jobs, and deletes it.
+  void DeleteJob(Job* job);
+
+  // Overridden from net::interfaces::HostResolverService:
+  void Resolve(interfaces::HostResolverRequestInfoPtr request_info,
+               interfaces::HostResolverRequestClientPtr client) override;
+
+  // Resolver for resolving incoming requests.
+  HostResolver* resolver_;
+
+  // All pending jobs, so they can be cancelled when this service is destroyed.
+  // Owns all jobs.
+  std::set<Job*> pending_jobs_;

[Sam McNally, 2015/02/05 23:58:36]

std::set<linked_ptr<Job>>

[Anand Mistry (off Chromium), 2015/02/06 06:32:40]

I tried that, but it ended up being fairly convoluted. Specifically, the
linked_ptr wasn't used anywhere, and you need to go from Job* to linked_ptr<Job>
and it just didn't look right.

+
+  base::ThreadChecker thread_checker_;
+
+  DISALLOW_COPY_AND_ASSIGN(HostResolverServiceImpl);
+};
+
+}  // namespace net
+
+#endif  // NET_DNS_HOST_RESOLVER_SERVICE_IMPL_H_