Add multi_process_lock to chrome/common

chrome/common/multi_process_lock_unittest.cc

Index: chrome/common/multi_process_lock_unittest.cc
diff --git a/chrome/common/multi_process_lock_unittest.cc b/chrome/common/multi_process_lock_unittest.cc
new file mode 100644
index 0000000000000000000000000000000000000000..aeb6758c573b57d07f7a7fc9868d753b6b239602
--- /dev/null
+++ b/chrome/common/multi_process_lock_unittest.cc
@@ -0,0 +1,71 @@
+// 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/basictypes.h"
+#include "base/scoped_ptr.h"
+#include "base/test/multiprocess_test.h"
+#include "chrome/common/multi_process_lock.h"
+#include "testing/multiprocess_func_list.h"
+
+static const char kMutexName[] = "shared_mutex_unittest";

[Mark Mentovai, 2010/11/12 17:58:28]

Should you randomize this name a little bit so that a hung test or two tests
running simultaneously or other badness won’t cause flake?

[dmac, 2010/11/15 23:02:13]

Done.

+
+class MultiProcessLockTest : public base::MultiProcessTest {
+};
+
+TEST_F(MultiProcessLockTest, BasicCreationTest) {
+  // Test basic creation/destruction with no lock taken
+  scoped_ptr<MultiProcessLock> scoped(MultiProcessLock::Create(kMutexName));
+  scoped.reset(NULL);
+}
+
+TEST_F(MultiProcessLockTest, LongNameTest) {
+  const char kLongName[] = "This is a name that is longer than one hundred and "
+      "four characters to make sure that we fail appropriately on linux when "
+      "we have a path that is to long for linux to handle.";

[Mark Mentovai, 2010/11/12 17:58:28]

Should the interface mandate a specific upper limit on all platforms for
consistency?

[dmac, 2010/11/15 23:02:13]

Done.

+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kLongName));
+#if defined(OS_LINUX)
+  EXPECT_FALSE(test_lock->TryLock());
+#else  // defined(OS_LINUX)
+  EXPECT_TRUE(test_lock->TryLock());
+#endif  // defined(OS_LINUX)
+}
+
+TEST_F(MultiProcessLockTest, SimpleLock) {
+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_TRUE(test_lock->TryLock());
+  base::ProcessHandle handle = SpawnChild("MultiProcessLockTryFailMain", false);
+  ASSERT_TRUE(handle);
+  int exit_code = 0;
+  EXPECT_TRUE(base::WaitForExitCode(handle, &exit_code));
+  EXPECT_EQ(exit_code, 0);
+  test_lock->Unlock();
+  handle = SpawnChild("MultiProcessLockTrySucceedMain", false);
+  ASSERT_TRUE(handle);
+  EXPECT_TRUE(base::WaitForExitCode(handle, &exit_code));
+  EXPECT_EQ(exit_code, 0);
+}
+
+TEST_F(MultiProcessLockTest, RecursiveLock) {
+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_TRUE(test_lock->TryLock());
+    // Will cause LOG in debug, but will complete.

[Mark Mentovai, 2010/11/12 17:58:28]

Indent?

Put a blank line before this so that it’s obvious that it applies to the second
TryLock.

[dmac, 2010/11/15 23:02:13]

Done.

+  EXPECT_TRUE(test_lock->TryLock());
+  test_lock->Unlock();
+    // Will cause LOG in debug, but will complete.

[Mark Mentovai, 2010/11/12 17:58:28]

Same.

[dmac, 2010/11/15 23:02:13]

Done.

+  test_lock->Unlock();
+  test_lock.reset();
+}
+

[Mark Mentovai, 2010/11/12 17:58:28]

You should have some sort of test that proves that a lock is released when it
goes out of scope. This would have caught your “oops, virtual destructor” bug
(and someone’s future similar bug.)

[dmac, 2010/11/15 23:02:13]

Done.

+MULTIPROCESS_TEST_MAIN(MultiProcessLockTryFailMain) {
+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_FALSE(test_lock->TryLock());
+  return 0;
+}
+
+
+MULTIPROCESS_TEST_MAIN(MultiProcessLockTrySucceedMain) {
+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_TRUE(test_lock->TryLock());
+  return 0;
+}