Fix history importing by delaying DownloadManager creation.

content/browser/download/download_id_factory.cc

+// 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.
+
+#include "content/browser/download/download_id_factory.h"
+
+#include "content/browser/download/download_id.h"
+
+DownloadIdFactory::DownloadIdFactory(DownloadId::Domain domain)
+  : domain_(domain),
+    next_id_(0) {
+}
+
+DownloadId DownloadIdFactory::GetNextId() {
+  base::AutoLock lock(lock_);

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

Is there a reason to use AutoLock rather than atomic_sequence_num.h?  I don't
care (I don't think this is performance critical); just making you aware of the
option.

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

We're planning on initializing next_id_ to something non-zero in the future, and
I don't see how to do that with AtomicSequenceNumber. We could store an offset_
alongside the AtomicSequenceNumber and always add in the offset_, but that
doesn't feel right. LMK if you would still prefer ASN+offset over lock+counter.

+  return DownloadId(domain_, next_id_++);
+}
+
+void DownloadIdFactory::SetNextId(int next_id) {
+  base::AutoLock lock(lock_);
+  next_id_ += next_id;

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

The += is strange enough that it deserves a comment (I say this especially
because I don't remember exactly what it's supposed to be gaining us, even after
I went back to the comment in download_manager.cc being deleted :-}).

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

We were thinking at one point that DM could allocate some ids, then increment
the id counter by the number read from the history, then resume allocating ids,
but this method is not necessary if we aren't reading the number from the
history, and won't be necessary if we can eventually read the number from the
history before creating the DIF.

+}