Create a content::ResourceContext.

content/browser/resource_context.h

Index: content/browser/resource_context.h
diff --git a/content/browser/resource_context.h b/content/browser/resource_context.h
new file mode 100644
index 0000000000000000000000000000000000000000..b98ab65bcf1e11ef998be7996bfda088a19c79e5
--- /dev/null
+++ b/content/browser/resource_context.h
@@ -0,0 +1,59 @@
+// Copyright (c) 2011 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 CONTENT_BROWSER_RESOURCE_CONTEXT_H_
+#define CONTENT_BROWSER_RESOURCE_CONTEXT_H_
+
+#include "base/basictypes.h"
+#include "base/memory/ref_counted.h"
+#include "base/threading/non_thread_safe.h"
+
+namespace webkit_database {
+class DatabaseTracker;
+}  // namespace webkit_database
+
+namespace content {
+
+// ResourceContext contains the relevant context information required for
+// resource loading. It lives on the IO thread.
+class ResourceContext : public base::NonThreadSafe {
+ public:
+  ResourceContext();
+  virtual ~ResourceContext();
+
+  webkit_database::DatabaseTracker* database_tracker() const;
+  void set_database_tracker(webkit_database::DatabaseTracker* tracker);
+
+ private:
+  scoped_refptr<webkit_database::DatabaseTracker> database_tracker_;
+
+  DISALLOW_COPY_AND_ASSIGN(ResourceContext);
+};
+
+// ResourceContextGetter is used purely for acquiring a ResourceContext on the

[jam, 2011/04/11 22:00:41]

is there any way we can avoid the getter pattern?  it adds copy & paste code to
each message filter that is used for a renderer&worker, since they each need
different constructors for UI/IO thread etc.  Can we we just have Profile return
a ResourceContext on the UI thread that can only be used on the IO thread?

[willchan no longer on Chromium, 2011/04/11 22:13:05]

It's a tradeoff. We lose the ability to use NonThreadSafe then (not too big a
deal, we can use BrowserThread::CurrentlyOn() assertions instead). Also, the
getter pattern lets us do lazy initialization of stuff contained in
URLRequestContext/ResourceContext, which actually has a noticeable impact on
startup now. Otherwise, for each accessor in ResourceContext (of which there
will be many in the future), we'll have to add in the lazy initialization code.

If this is any consolation, I expect to be able to get rid of all the
URLRequestContextGetters in content/ and replace them with a single
ResourceContextGetter. And I hope that there aren't too many message filters
that need to access the ResourceContextGetter, although I'm really not sure.

I'd like to see Eric weigh in here if he notices this.

+// IO thread, via Get(). Afterwards, it should be cached. Any object that caches
+// the ResourceContext pointer should have a shorter lifetime than the
+// ResourceContext.
+class ResourceContextGetter {
+ public:
+  virtual ~ResourceContextGetter();
+
+  // Returns a ResourceContext. It's only allowed to be called once. Any
+  // subsequent attempts will crash.
+  const ResourceContext& Get();
+
+ protected:
+  ResourceContextGetter();
+
+ private:
+  virtual const ResourceContext& GetImpl() = 0;
+
+  bool called_get_;
+
+  DISALLOW_COPY_AND_ASSIGN(ResourceContextGetter);
+};
+
+}  // namespace content
+
+#endif  // CONTENT_BROWSER_RESOURCE_CONTEXT_H_