Add multi_process_lock to chrome/common

chrome/common/multi_process_lock_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 "build/build_config.h"
+
+#if defined(OS_LINUX)
+#include <sys/un.h>
+#endif  // defined(OS_LINUX)
+
+#include "base/basictypes.h"
+#include "base/scoped_ptr.h"
+#include "base/stringprintf.h"
+#include "base/test/multiprocess_test.h"
+#include "chrome/common/multi_process_lock.h"
+#include "testing/multiprocess_func_list.h"
+
+static char kMutexName[] = "shared_mutex_unittest " __DATE__ " " __TIME__;

[Mark Mentovai, 2010/11/15 23:42:55]

This is no good. Multiple invocations of the same binary will still sit on top
of one another. This isn’t a good candidate for use of __DATE__ and __TIME__.
Throwing some runtime randomness at the problem would be fine.

[dmac, 2010/11/15 23:55:24]

How do you suggest adding the randomness you seek? Remember that the
subprocesses that are launched need to have the same mutex name so that they can
look them up. I looked into using pids to do this and found that we don't have
code to get the parent pid on windows. I thought this was a reasonable
compromise.

[Mark Mentovai, 2010/11/16 04:05:50]

Can you pass a cookie to the processes on the command line? Or use the
environment?

[dmac, 2010/11/16 17:54:17]

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) {
+  // Linux has a max path name of 108 characters.
+  // http://lxr.linux.no/linux+v2.6.36/include/linux/un.h
+  // This is enforced on all platforms.
+  std::string name("This is a name that is longer than one hundred and eight "
+      "characters to make sure that we fail appropriately on linux when we "
+      "have a path that is to long for linux to handle " __DATE__ " " __TIME__);

[Mark Mentovai, 2010/11/15 23:42:55]

And these guys are just gratuitous. Take them out.

(My __DATE__ and __TIME__ vendetta partially stems from the fact that they’re
sort of ambiguous in light of rebuilds and systems that cache object files that
result from compilation.)

[dmac, 2010/11/16 17:54:17]

Done.

+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(name));
+  EXPECT_FALSE(test_lock->TryLock());
+}
+
+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.
+  EXPECT_TRUE(test_lock->TryLock());
+  test_lock->Unlock();
+
+  // Will cause LOG in debug, but will complete.
+  test_lock->Unlock();
+  test_lock.reset();
+}
+
+TEST_F(MultiProcessLockTest, LockScope) {
+  // Check to see that lock is released when it goes out of scope.

[Mark Mentovai, 2010/11/15 23:42:55]

This doesn’t really check with {scoping}, which is kind of what I was hoping
for.

[dmac, 2010/11/15 23:55:24]

Why isn't the scoped_ptr with a reset not giving us a scoping check?

[Mark Mentovai, 2010/11/16 04:05:50]

It simulates it, but I was hoping for a check that actually worked with crossing
a scope boundary, because I envision that as a possible use case for this code.

[dmac, 2010/11/16 17:54:17]

Done.

+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_TRUE(test_lock->TryLock());
+  test_lock.reset(MultiProcessLock::Create(kMutexName));
+  EXPECT_TRUE(test_lock->TryLock());

[Mark Mentovai, 2010/11/15 23:42:55]

Also, this will still be true if the lock is still held from the preceding
TryLock (if the Unlock doesn’t happen for some reason, like a destructor not
marked virtual). This doesn’t make a very thorough test.

[dmac, 2010/11/15 23:55:24]

Good point. I'll look into this one... 

[dmac, 2010/11/16 17:54:17]

Done.

+  test_lock.reset();
+}
+
+#if defined(OS_LINUX)
+TEST_F(MultiProcessLockTest, MaxNameLength) {

[Mark Mentovai, 2010/11/15 23:42:55]

Ah, I see what you’ve done.

I think the COMPILE_ASSERT in the Linux implementation file is better, though.

(See base/logging.h.)

[dmac, 2010/11/15 23:55:24]

Ah... missed the assert. Went looking for it, and didn't find it.

[dmac, 2010/11/16 17:54:17]

Done.

+  // +1 for terminator, +1 for 0 in position 0 that makes it an
+  // abstract named socket.
+  // If this test fails it is because sockaddr_un.sun_path size has been
+  // redefined and MULTI_PROCESS_LOCK_NAME_MAX_LEN can change accordingly.
+  // Only tested on Linux because it is the only platform that has a limit.
+  struct sockaddr_un addr;
+  EXPECT_EQ(sizeof(addr.sun_path),
+            MultiProcessLock::MULTI_PROCESS_LOCK_NAME_MAX_LEN + 2);
+}
+#endif  // defined(OS_LINUX)
+
+MULTIPROCESS_TEST_MAIN(MultiProcessLockTryFailMain) {
+  scoped_ptr<MultiProcessLock> test_lock(MultiProcessLock::Create(kMutexName));
+  EXPECT_FALSE(test_lock->TryLock());
+  return 0;
+}
+
+

[Mark Mentovai, 2010/11/15 23:42:55]

Extra blank line.

[dmac, 2010/11/16 17:54:17]

Done.

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