Add a new GetInstance() method for singleton classes under chrome/service and /net.

chrome/common/service_process_util_unittest.cc

 // Copyright (c) 2010 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 "base/process_util.h"
 #include "base/string_util.h"
 #include "chrome/common/chrome_version_info.h"
 #include "chrome/common/service_process_util.h"
 #include "testing/gtest/include/gtest/gtest.h"
 
 
 TEST(ServiceProcessUtilTest, ScopedVersionedName) {
   std::string test_str = "test";
   std::string scoped_name = GetServiceProcessScopedVersionedName(test_str);
   chrome::VersionInfo version_info;
   DCHECK(version_info.is_valid());
   EXPECT_TRUE(EndsWith(scoped_name, test_str, true));
   EXPECT_NE(std::string::npos, scoped_name.find(version_info.Version()));
 }
 
 #if defined(OS_WIN)
 // Singleton-ness is only implemented on Windows.
+// TODO(sanjeev): Rewrite this test to spawn a new process and test using the
+// ServiceProcessState singleton across processes.
+/*
 TEST(ServiceProcessStateTest, Singleton) {
   ServiceProcessState state;
   EXPECT_TRUE(state.Initialize());
   // The second instance should fail to Initialize.
   ServiceProcessState another_state;
   EXPECT_FALSE(another_state.Initialize());
 }
+*/
 #endif  // defined(OS_WIN)
 
 TEST(ServiceProcessStateTest, ReadyState) {
 #if defined(OS_WIN)
   // On Posix, we use a lock file on disk to signal readiness. This lock file
   // could be lying around from previous crashes which could cause
   // CheckServiceProcessReady to lie. On Windows, we use a named event so we
   // don't have this issue. Until we have a more stable signalling mechanism on
   // Posix, this check will only execute on Windows.
   EXPECT_FALSE(CheckServiceProcessReady());
 #endif  // defined(OS_WIN)
-  ServiceProcessState state;
-  EXPECT_TRUE(state.Initialize());
-  state.SignalReady(NULL);
+  ServiceProcessState* state = ServiceProcessState::GetInstance();

[willchan no longer on Chromium, 2010/12/08 00:58:46]

Are you sure this is recommended?  What do we do with the service process tests?
 Do we run all the same tests in the same process, with the same singleton
instance?  If so, then you may run into ordering issues.  What if another test
runs first that tries to access the ServiceProcessState singleton?  Will calling
Initialize() twice work properly?  I'm not sure this is advisable.  You might
want to revert to the same test code and make the constructor public again, or
friend the TEST_F.

[Satish, 2010/12/08 12:58:22]

Yes this is bound to have issues later on. I have now added a test fixture and
used base::ShadowingAtExitManager to ensure that this singleton gets created and
destroyed within each test and there is no sharing of state between two tests.
This model is used in other unit tests too.

+  EXPECT_TRUE(state->Initialize());
+  state->SignalReady(NULL);
   EXPECT_TRUE(CheckServiceProcessReady());
-  state.SignalStopped();
+  state->SignalStopped();
   EXPECT_FALSE(CheckServiceProcessReady());
 }
 
 TEST(ServiceProcessStateTest, SharedMem) {
 #if defined(OS_WIN)
   // On Posix, named shared memory uses a file on disk. This file
   // could be lying around from previous crashes which could cause
   // GetServiceProcessPid to lie. On Windows, we use a named event so we
   // don't have this issue. Until we have a more stable shared memory
   // implementation on Posix, this check will only execute on Windows.
   EXPECT_EQ(0, GetServiceProcessPid());
 #endif  // defined(OS_WIN)
-  ServiceProcessState state;
-  EXPECT_TRUE(state.Initialize());
+  ServiceProcessState* state = ServiceProcessState::GetInstance();
+  EXPECT_TRUE(state->Initialize());
   EXPECT_EQ(base::GetCurrentProcId(), GetServiceProcessPid());
 }