Add multi_process_lock to chrome/common

chrome/common/multi_process_lock.h

Index: chrome/common/multi_process_lock.h
diff --git a/chrome/common/multi_process_lock.h b/chrome/common/multi_process_lock.h
new file mode 100644
index 0000000000000000000000000000000000000000..b30426e53779ce367d7742660eef1c225a417a63
--- /dev/null
+++ b/chrome/common/multi_process_lock.h
@@ -0,0 +1,35 @@
+// 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.
+
+#ifndef CHROME_COMMON_MULTI_PROCESS_LOCK_H_
+#define CHROME_COMMON_MULTI_PROCESS_LOCK_H_
+#pragma once
+
+#include <string>
+
+// Platform abstraction for a lock that can be shared between processes.
+// The process that owns the lock will release it on exit even if the exit is
+// due to a crash.
+class MultiProcessLock {
+ public:
+  // Factory method for creating a multi process lock.
+  // |name| is the name of the lock. The name has special meaning on Windows
+  // where the prefix can determine the namespace of the lock.
+  // See http://msdn.microsoft.com/en-us/library/aa382954(v=VS.85).aspx for
+  // details.
+  static MultiProcessLock* Create(const std::string& name);
+
+  // Try to grab ownership of the lock.
+  virtual bool TryLock() = 0;

[Mark Mentovai, 2010/11/11 22:08:27]

Once you write “virtual” you should think long and hard about declaring a
virtual destructor. Actually, you shouldn’t have to think too long or too hard,
you should just provide one. And in this case, it’s the right thing to do.

As it stands now, any likely implementation that would use this code would leak
like a sieve.

[dmac, 2010/11/11 23:33:02]

Rookie mistake. D'oh. Done. Good catch.

+
+  // Release ownership of the lock.
+  virtual void Unlock() = 0;
+
+ protected:

[Mark Mentovai, 2010/11/11 22:08:27]

protected sucks. I don’t think you need the constructor or the variable here. I
think they properly belong defined individually on each of the concrete derived
implementations, as needed. It’s up to those implementations if they even need
to keep name_ around, if the constructor will work based on a name parameter or
something else (or a name parameter in addition to something else), etc…

(If you must, you can declare the MultiProcessLock() constructor as protected
and do-nothing, but it doesn’t make much of a practical difference because this
class is pure abstract.)

[dmac, 2010/11/11 23:33:02]

I disagree that protected sucks, but hey. I agree with you that name_ should be
pushed down into the impls.

+  explicit MultiProcessLock(const std::string& name) : name_(name) { }
+
+  std::string name_;
+};

[Mark Mentovai, 2010/11/11 22:08:27]

#include "base/basictypes.h"
[...]
 private:
  DISALLOW_COPY_AND_ASSIGN(MultiProcessLock);

Right?

[dmac, 2010/11/11 23:33:02]

Is that intended as "is this correct?"

It doesn't hurt, but you are correct that it is unnecessary for a pure virtual
class.

Done. 

+
+#endif  // CHROME_COMMON_MULTI_PROCESS_LOCK_H_