[wip] Profile: Sketch of a creation system.

chrome/browser/profiles/profile_impl.cc

Index: chrome/browser/profiles/profile_impl.cc
diff --git a/chrome/browser/profiles/profile_impl.cc b/chrome/browser/profiles/profile_impl.cc
index 4981a1b9199adc13545769b51f26c26e51acd8bc..f5a3c64aa0c0a5d24ed57854fdc0005fb16d57a0 100644
--- a/chrome/browser/profiles/profile_impl.cc
+++ b/chrome/browser/profiles/profile_impl.cc
@@ -295,10 +295,6 @@ ProfileImpl::ProfileImpl(const FilePath& path,
   DCHECK(!path.empty()) << "Using an empty path will attempt to write " <<
                             "profile files to the root directory!";
 
-#ifndef NDEBUG
-    ProfileDependencyManager::GetInstance()->ProfileNowExists(this);
-#endif
-
   create_session_service_timer_.Start(
       TimeDelta::FromMilliseconds(kCreateSessionServiceDelayMS), this,
       &ProfileImpl::EnsureSessionServiceCreated);

[Elliot Glaysher, 2011/06/30 23:55:03]

Why do we do this? Things seem to work if I leave this out.

[Miranda Callahan, 2011/07/01 15:20:24]

Good question. I tracked through the code and saw no clear reason to delay; svn
annotation says that this line was part of the original commit. Maybe the thing
to do is take it out in a CL on its own, so it's easier to track any possible
weird consequences (startup regressions, races between the session service
getting the initial BROWSER_OPENED notification, and the construction of the
profile (which is now partially asynchronous), unknown unknowns, etc. ...)

But removing 500ms delays that seem groundless sounds like a Very Good Thing.

@@ -819,6 +815,8 @@ void ProfileImpl::OnPrefsLoaded(bool success) {
   // Make sure we save to disk that the session has opened.
   prefs_->ScheduleSavePersistentPrefs();
 
+  ProfileDependencyManager::GetInstance()->CreateProfileServices(this, false);
+
   // Ensure that preferences set by extensions are restored in the profile
   // as early as possible. The constructor takes care of that.
   extension_prefs_.reset(new ExtensionPrefs(