Cache Backend Proxy to intercept all cache events from the IO thread.

net/net.gyp

Index: net/net.gyp
diff --git a/net/net.gyp b/net/net.gyp
index fcbb2e8eb21d7dad06412588a62f712382a5d4b1..fe47491628630b8e4005049ec3155f8db619a088 100644
--- a/net/net.gyp
+++ b/net/net.gyp
@@ -7,6 +7,7 @@
     'chromium_code': 1,
 
     'linux_link_kerberos%': 0,
+    'use_tracing_cache_backend%': 0,
     'conditions': [
       ['chromeos==1 or OS=="android" or OS=="ios"', {
         # Disable Kerberos on ChromeOS, Android and iOS, at least for now.
@@ -381,6 +382,8 @@
         'disk_cache/stress_support.h',
         'disk_cache/trace.cc',
         'disk_cache/trace.h',
+        'disk_cache/tracing_cache_backend.cc',
+        'disk_cache/tracing_cache_backend.h',
         'disk_cache/simple/simple_backend_impl.cc',
         'disk_cache/simple/simple_backend_impl.h',
         'disk_cache/simple/simple_disk_format.cc',
@@ -1081,6 +1084,17 @@
             'dns/dns_client.cc',
           ],
         }],
+        ['use_tracing_cache_backend==1', {
+          'defines': [
+            'USE_TRACING_CACHE_BACKEND'
+          ],
+         },
+         { # else
+           'sources!': [
+             'disk_cache/tracing_cache_backend.cc',
+             'disk_cache/tracing_cache_backend.h',
+           ],
+         }],
         ['use_openssl==1', {
             'sources!': [
               'base/crypto_module_nss.cc',
@@ -2003,6 +2017,8 @@
         'disk_cache/disk_cache_test_util.h',
         'disk_cache/flash/flash_cache_test_base.h',
         'disk_cache/flash/flash_cache_test_base.cc',
+        'disk_cache/tracing_cache_backend.cc',

[rvargas (doing something else), 2013/04/05 19:25:13]

I don't like adding the same files to two different targets... especially if
they may end up compiled into the same executable.

Why not just add the files to net all the time? You could still add the define
based on a gyp variable if you want.

[pasko-google - do not use, 2013/04/08 15:37:40]

The reason was to save on compiled binary size. There is going to be 2 more
files which may even deserve a static library that we could link in
conditionally. WDYT? Would that look better?

As you suggest we would pay the price for the binary size to avoid repeating the
files twice in the gyp file, but we still would not get the benefit of being
able to turn it on at runtime. Am I right? I do not like this specific set of
limitations.

[rvargas (doing something else), 2013/04/08 18:28:34]

Saving binary size should be the job of the linker. If nobody uses the class on
a regular build, the code should be optimized out.
please don't do that. 3 files don't (generally) make a static library. Static
libraries increase complexity of gyp and or increase the number of dynamic
libraries that we have to build for the components build... which is not a good
thing. In this specific case, that would mean net depending on a library that
depends on net...
There should be no binary size issue when the code is not used... and it solves
the issue of including the same code multiple times when building tools... plus
the funky issue with the define in unit tests that attempts to catch errors
(without success because nothing prevents the definition of
USE_TRACING_CACHE_BACKEND for net while that definition is invisible to unit
tests).

I think that trying to add or remove files with gyp to various targets depending
on gyp variables only make things more complicated and error prone. To be clear,
just removing the files from net would be fine, but once we need to add them
back into the test executable we enter murky waters.

[pasko-google - do not use, 2013/04/09 11:53:17]

I am relying on the linker now. Thanks.

Generally it is not ideal: it takes only two non-careful engineers to reuse a
constant from the file and suddenly the whole set of heavy files is linked in.
It is not easy to write a test against unwanted linkages, so in the end a
"trivial one-liner" pulls in too much. On the other hand if owners in net/ are
used to watching on accidental reuses in previously optional files, everything
is fine. I just did not assume reviewers are as careful.

+        'disk_cache/tracing_cache_backend.h',
         'dns/dns_test_util.cc',
         'dns/dns_test_util.h',
         'dns/mock_host_resolver.cc',