Collect some histograms about signed binary downloads.

chrome/browser/safe_browsing/safe_browsing_service.h

Index: chrome/browser/safe_browsing/safe_browsing_service.h
===================================================================
--- chrome/browser/safe_browsing/safe_browsing_service.h	(revision 106177)
+++ chrome/browser/safe_browsing/safe_browsing_service.h	(working copy)
@@ -18,6 +18,7 @@
 #include "base/hash_tables.h"
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_ptr.h"
+#include "base/memory/weak_ptr.h"
 #include "base/observer_list.h"
 #include "base/synchronization/lock.h"
 #include "base/task.h"
@@ -50,6 +51,7 @@
 // Construction needs to happen on the main thread.
 class SafeBrowsingService
     : public base::RefCountedThreadSafe<SafeBrowsingService>,
+      public base::SupportsWeakPtr<SafeBrowsingService>,

[mattm, 2011/10/19 18:54:12]

Are you aiming to make SafeBrowsingService not refcounted in the future?  Should
add a comment why this is both refcounted and SupportsWeakPtr.

[Brian Ryner, 2011/10/19 19:20:11]

So, the issue I'm trying to address here is that currently, there's a circular
reference: SafeBrowsingService has a reference to DownloadProtectionService, and
DownloadProtectionService has a reference to SafeBrowsingService.

The cycle can be broken by calling SafeBrowsingService::ShutDown, but that isn't
something that is consistently called in various tests that use
SafeBrowsingSservice.  It seemed like it might be less error-prone to have a
strong reference going in only one direction.

Does that make sense, or do you think there's a better way to address this?

[mattm, 2011/10/19 20:04:10]

Still thinking this through, but I think we could:

Make DownloadProtectionService not refcounted at all, but instead
SupportsWeakPtr.  SafeBrowsingService would own the DownloadProtectionService,
and thus we could be sure that the SBService outlives the DPService.  Any time
we post a task for the DPService we'd use a WeakPtr, and those would be safe
since they would each be created only as needed rather than having a long-lived
one like this that would be accessed on multiple threads.

Does that sound sane?

On 2011/10/19 19:20:11, Brian Ryner wrote:

[mattm, 2011/10/19 20:06:07]

Oh, the one thing I forgot to mention: Since we are sure about the lifetime
being longer, then DownloadProtectionService would hold a bare pointer to
SafeBrowsingService instead of a refptr, breaking the cycle.

On 2011/10/19 20:04:10, mattm wrote:

       public NotificationObserver {
  public:
   class Client;