Fix history importing by delaying DownloadManager creation.

content/browser/download/download_id_factory.h

+// 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 CHROME_BROWSER_DOWNLOAD_DOWNLOAD_ID_FACTORY_H_
+#define CHROME_BROWSER_DOWNLOAD_DOWNLOAD_ID_FACTORY_H_
+#pragma once
+
+#include "base/memory/ref_counted.h"
+#include "base/synchronization/lock.h"
+#include "content/browser/browser_thread.h"
+#include "content/browser/download/download_id.h"
+
+class DownloadManager;
+
+class CONTENT_EXPORT DownloadIdFactory
+    : public base::RefCountedThreadSafe<DownloadIdFactory> {
+ public:
+  DownloadIdFactory(DownloadId::Domain domain);
+
+  DownloadId GetNextId();
+
+  void SetNextId(int next_id);

[Randy Smith (Not in Mondays), 2011/10/27 18:01:44]

Remind me what the constraints are on our use of this function?  It doesn't look
like we're currently using it, and in the future I think we'll be constructing
the DownloadIdFactory with information from the history database, so it'll
belong as part of the constructor.  I have a memory that there are medium-term
constraints on the relationship between db_handle and id, but I don't remember
what they are.  

[benjhayden, 2011/10/27 19:04:41]

We'd been thinking at one point that, until the id is persisted, we can allocate
some ids then increment the factory counter by the number read from the history,
then resume allocating ids, but I don't think that's necessary if we aren't
reading the number from the history. Is that what you're thinking of?
I'll remove the method.

[Randy Smith (Not in Mondays), 2011/10/28 13:35:43]

That's what I was thinking of--I wish I remembered what the motivation for the
+= was (what it would give us).  Ah, well, if it was important it'll call back
:-}.

[benjhayden, 2011/10/28 14:37:54]

We want to set next_id_ = next_id_from_history, but we were worried that an id
could be allocated before the history callback was called, which might cause us
to allocate the same id twice. I think that we could have also said next_id_ =
max(next_id_, next_id_from_history), but I think that we're safe now either way.

+
+ private:
+  DownloadId::Domain domain_;
+  int next_id_;
+  base::Lock lock_;
+
+  DISALLOW_COPY_AND_ASSIGN(DownloadIdFactory);
+};
+
+#endif  // CHROME_BROWSER_DOWNLOAD_DOWNLOAD_ID_FACTORY_H_