Add Get/SetUniqueIdForProcess.

base/process/process_handle.cc

Index: base/process/process_handle.cc
diff --git a/base/process/process_handle.cc b/base/process/process_handle.cc
new file mode 100644
index 0000000000000000000000000000000000000000..c4de20a2f0e9630ef5f589b096e0a56d7d9182ac
--- /dev/null
+++ b/base/process/process_handle.cc
@@ -0,0 +1,41 @@
+// Copyright 2015 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/logging.h"
+#include "base/process/process_handle.h"
+
+namespace base {
+
+namespace {
+uint32 g_unique_id = kInvalidUniqueId;
+
+#ifndef NDEBUG
+// The process which set g_unique_id.
+uint32 g_procid;
+#endif
+}  // namespace
+
+uint32 GetUniqueIdForProcess() {
+  if (g_unique_id == kInvalidUniqueId) {
+    return static_cast<uint32>(GetCurrentProcId());

[danakj, 2015/06/17 17:17:16]

Should SetUniqueId(GetCurrentProcId()) here so we don't return inconsistent
things?

[rickyz (no longer on Chrome), 2015/06/17 19:53:41]

If we call SetUniqueIdForProcess here, then GetUniqueIdForProcess would return
an incorrect value after the process forks (which is also the only situation
where an inconsistent value might be returned by GetCurrentProcId). It'd also
make GetCurrentProcId non thread-safe. I'm kind of on the fence about whether we
should support forking after calling SetUniqueIdForProcess at all (see the
response to willchan@'s comment in SetUniqueIdForProcess), but leaning towards
leaving things more flexible for the moment.

+  }
+
+#ifndef NDEBUG

[willchan no longer on Chromium, 2015/06/17 01:51:44]

Why bother with NDEBUG if using DCHECK_EQ? Is there another side effect I'm
missing?

[rickyz (no longer on Chrome), 2015/06/17 03:04:06]

I kept the explicit ifndef because I saw that there was a DCHECK_ALWAYS_ON macro
that could enable DCHECKs even with NDEBUG is set - also, if I read correctly,
it looks like DCHECK_EQ will still evaluate to code that references the variable
- it just relies on the compiler to omit that code since it ends up inside an if
(0).

[danakj, 2015/06/17 17:09:53]

It avoids unused variable warnings when compiled out, but does not run the code
inside. DCHECK_IS_ON means we want dchecks, otherwise we don't. Why do you only
want this dcheck in a debug build? Then it will not run on the bots.

[danakj, 2015/06/17 17:17:16]

You can guard all your NDEBUG code with #if DCHECK_IS_ON() instead and it'll do
the right thing.

[rickyz (no longer on Chrome), 2015/06/17 19:53:41]

Ah, good point.

+  // Make sure we are the same process that set g_procid. This check may have
+  // false negatives (if a process ID was reused) but should have no false
+  // positives.
+  DCHECK_EQ(static_cast<uint32>(GetCurrentProcId()), g_procid);
+#endif
+  return g_unique_id;
+}
+
+void SetUniqueIdForProcess(uint32 unique_id) {
+  g_unique_id = unique_id;

[willchan no longer on Chromium, 2015/06/17 01:51:45]

This shouldn't be set twice, right? I wonder if it'd be good to
DCHECK_EQ(kInvalidUniqueId, g_unique_id);

[rickyz (no longer on Chrome), 2015/06/17 03:04:05]

In practice, this really shouldn't be set twice - I left in the possibility
because a child process could potentially fork again and want to set this - in
that case though, the child would need to ensure that it doesn't end up relying
on any references to the old unique id in memory, which seems a little fragile -
jln@, what are your thoughts on this?

+#ifndef NDEBUG
+  g_procid = static_cast<uint32>(GetCurrentProcId());

[danakj, 2015/06/17 17:17:16]

How useful is this if GetCurrentProcId() is always 1?

[rickyz (no longer on Chrome), 2015/06/17 19:53:41]

GetCurrentProcId is only 1 in processes which are in separate PID namespaces, so
for example, it'd return 1 on renderer processes if PID namespaces are
supported, but some other number on the browser process.

+#endif
+}
+
+}  // namespace base