[wip] Profile: Sketch of a creation system.

chrome/browser/profiles/profile_dependency_manager.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 "chrome/browser/profiles/profile_dependency_manager.h"
 
 #include <algorithm>
 #include <deque>
 #include <iterator>
 
+#include "chrome/browser/background/background_contents_service_factory.h"
 #include "chrome/browser/profiles/profile_keyed_service.h"
 #include "chrome/browser/profiles/profile_keyed_service_factory.h"
+#include "chrome/browser/search_engines/template_url_service_factory.h"
+#include "chrome/browser/sessions/session_service_factory.h"
+#include "chrome/browser/sessions/tab_restore_service_factory.h"
 #include "content/common/notification_service.h"
 
 class Profile;
 
+namespace {
+
+bool g_initialized = false;
+
+// TODO(erg): This needs to be something else. I don't think putting every
+// FooServiceFactory here will scale or is desireable long term.

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

Does anyone have any ideas on something cleaner here?

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

Perhaps I'm not seeing the problem correctly, but I don't see this method as
terribly unclean.

I see the problem thusly: we have a set of services that need to start up on
Profile creation. Having them all collected in a single place (instead of spread
out throughout initialization, as they are now) seems like a positive thing.

A couple questions, though:

1. It seems to me as if we should only use this method for factories that *must*
be initialized during Profile creation; as many factories as possible shouldn't
be created here, but instead be lazily created on first access. (I think this
also implies that our scaling problems may not be as bad as one might at first
fear.)

2. Why is the TabRestoreServiceFactory initialized here, instead of lazily at
first usage (probably in the Browser ctor, AFAICT)?

3. Same with TemplateURLServiceFactory.

Do we gain something by pulling creation up front instead of amortizing lazily
on access that I'm not seeing clearly?

[Elliot Glaysher, 2011/07/01 17:29:45]

And what about their dependencies? And once we add their dependencies, why not
add everything for clarity?
Because its testing usage isn't lazy; TabRestoreServiceFactory needs to be
active to say "TestingProfiles should have NULL mes by default." 

[Miranda Callahan, 2011/07/01 19:00:21]

Ok, "what about their dependencies" is a good argument. 

I still think this is a clean solution: it limits knowledge of the
ServiceFactory classes being initialized to the DependencyManager, and it places
their initialization in exactly the right spot.
If there are many of these cases, would it make sense to have a special
TestAssertFactoriesBuilt method that's called only in the testing case? 

[Elliot Glaysher, 2011/07/06 17:26:18]

I am not sure what you're proposing.

+void AssertFactoriesBuilt() {
+  if (!g_initialized) {
+    BackgroundContentsServiceFactory::GetInstance();
+    SessionServiceFactory::GetInstance();
+    TabRestoreServiceFactory::GetInstance();
+    TemplateURLServiceFactory::GetInstance();
+
+    g_initialized = true;
+  }
+}
+
+}  // namespace
+
 void ProfileDependencyManager::AddComponent(
     ProfileKeyedServiceFactory* component) {
   all_components_.push_back(component);
   destruction_order_.clear();
 }
 
 void ProfileDependencyManager::RemoveComponent(
     ProfileKeyedServiceFactory* component) {
   all_components_.erase(std::remove(all_components_.begin(),
                                     all_components_.end(),
@@ skipping 12 matching lines @@
 
   destruction_order_.clear();
 }
 
 void ProfileDependencyManager::AddEdge(ProfileKeyedServiceFactory* depended,
                                        ProfileKeyedServiceFactory* dependee) {
   edges_.insert(std::make_pair(depended, dependee));
   destruction_order_.clear();
 }
 
+void ProfileDependencyManager::CreateProfileServices(Profile* profile,
+                                                     bool is_testing_profile) {
+#ifndef NDEBUG
+  // Unmark |profile| as dead. This exists because of unit tests, which will
+  // often have similar stack structures. 0xWhatever might be created, go out
+  // of scope, and then a new Profile object might be created at 0xWhatever.
+  dead_profile_pointers_.erase(profile);
+#endif
+
+  AssertFactoriesBuilt();
+
+  // Iterate in reverse destruction order for creation.

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

You'll probably have to call BuildDestructionOrder here first, right?

[Elliot Glaysher, 2011/07/01 17:29:45]

Done.

+  for (std::vector<ProfileKeyedServiceFactory*>::reverse_iterator rit =
+           destruction_order_.rbegin(); rit != destruction_order_.rend();
+       ++rit) {
+    if (is_testing_profile && (*rit)->ServiceIsNULLWhileTesting()) {
+      (*rit)->SetTestingFactory(profile, NULL);
+    } else if ((*rit)->ServiceIsCreatedWithProfile()) {
+      // Create the service.
+      (*rit)->GetServiceForProfile(profile, true);
+    }
+  }
+}
+
 void ProfileDependencyManager::DestroyProfileServices(Profile* profile) {
   if (destruction_order_.empty())
     BuildDestructionOrder();
 
   for (std::vector<ProfileKeyedServiceFactory*>::const_iterator it =
            destruction_order_.begin(); it != destruction_order_.end(); ++it) {
     (*it)->ProfileShutdown(profile);
   }
 
 #ifndef NDEBUG
   // The profile is now dead to the rest of the program.
   dead_profile_pointers_.insert(profile);
 #endif
 
   for (std::vector<ProfileKeyedServiceFactory*>::const_iterator it =
            destruction_order_.begin(); it != destruction_order_.end(); ++it) {
     (*it)->ProfileDestroyed(profile);
   }
 }
 
 #ifndef NDEBUG
-void ProfileDependencyManager::ProfileNowExists(Profile* profile) {
-  dead_profile_pointers_.erase(profile);
-}
-
 void ProfileDependencyManager::AssertProfileWasntDestroyed(Profile* profile) {
   if (dead_profile_pointers_.find(profile) != dead_profile_pointers_.end()) {
     NOTREACHED() << "Attempted to access a Profile that was ShutDown(). This "
                  << "is most likely a heap smasher in progress. After "
                  << "ProfileKeyedService::Shutdown() completes, your service "
                  << "MUST NOT refer to depended Profile services again.";
   }
 }
 #endif
 
@@ skipping 50 matching lines @@
     }
   }
 
   if (edges.size()) {
     NOTREACHED() << "Dependency graph has a cycle. We are doomed.";
   }
 
   std::reverse(output.begin(), output.end());
   destruction_order_ = output;
 }