Add fine grain tracing to HostResolverImpl....

net/base/host_resolver.h

Index: net/base/host_resolver.h
===================================================================
--- net/base/host_resolver.h	(revision 37608)
+++ net/base/host_resolver.h	(working copy)
@@ -147,10 +147,6 @@
   // Unregisters an observer previously added by AddObserver().
   virtual void RemoveObserver(Observer* observer) = 0;
 
-  // Returns the host cache, or NULL if this implementation does not use
-  // a HostCache.
-  virtual HostCache* GetHostCache() = 0;
-
   // TODO(eroman): temp hack for http://crbug.com/18373
   virtual void Shutdown() = 0;
 
@@ -160,6 +156,8 @@
   // AF_INET6 by passing in ADDRESS_FAMILY_IPV6.
   virtual void SetDefaultAddressFamily(AddressFamily address_family) {}
 
+  virtual bool IsHostResolverImpl() { return false; }

[willchan no longer on Chromium, 2010/02/01 19:31:01]

My first gut reaction was "ew".  This looks ugly.  I see now that you need it in
URLRequestViewNetInternalsJob.  That is unfortunate.  I don't know how the
URLRequestViewNetInternalsJob code is hooked in, but my impression is that we
should only register the fine tracing stuff if we know that we're using the
HostResolverImpl.  So at the point where we decide (which is in IOThread when we
create the host resolver), we can also register the fine tracing stuff in
URLRequestViewNetInternalsJob.  I'm not sure if this is a reasonable approach. 
That's just my gut instinct of how this should work because I don't like to have
this cheapo re-implementation of RTTI.  That said, doing my solution might be
impractical or too much effort to be worth the gain.  So if you don't think my
suggestion works, then I'd be ok letting this go in.  I just think it's ugly,
but sometimes the uglier solution is good enough (and it doesn't look likely to
be abused further, at least I hope).

[eroman, 2010/02/01 20:31:25]

I agree that this is ugly. Here is my justification.

Previously, we had this GetCache() virtual method on the HostResolver interface,
which was basically the same sort of hack but narrower in scope. Everything
except HostResolverImpl would return NULL. URLRequestViewNetInternalsJob and the
"flush cache when leaving incognito mode" were the only consumers of this.

So now when I wanted to add more stuff (for the tracing), it felt wrong to force
them into the base interface in the same manner, since then HostResolver becomes
bloated. 

I am not too excited about a registration based system (setting up the
URLRequestViewNetInternalsJob to "know" what the host resolver is), since it
doesn't address the incognito consumer (unless that too were to use the
registration paradigm), and it makes it more difficult to swap host resolvers at
runtime.

In the spirit of expediency, I am inclined to leave this as is. But I will
definitely interested in finding a better solution, and will give it more
thought.

[willchan no longer on Chromium, 2010/02/01 21:27:33]

Yes, I'd imagine the incognito consumer would have to know too.  I agree this
solution isn't exactly pretty either.
Sounds fine to me.

+
  protected:
   friend class base::RefCountedThreadSafe<HostResolver>;