Add ScopedKeepAlive to c/b/lifetime

chrome/browser/lifetime/keep_alive_registry.h

Index: chrome/browser/lifetime/keep_alive_registry.h
diff --git a/chrome/browser/lifetime/keep_alive_registry.h b/chrome/browser/lifetime/keep_alive_registry.h
new file mode 100644
index 0000000000000000000000000000000000000000..b521bbb39c3cbf726be7808da2317cfe2ce6243e
--- /dev/null
+++ b/chrome/browser/lifetime/keep_alive_registry.h
@@ -0,0 +1,32 @@
+// Copyright 2016 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_BROWSER_LIFETIME_KEEP_ALIVE_REGISTRY_H_
+#define CHROME_BROWSER_LIFETIME_KEEP_ALIVE_REGISTRY_H_
+
+#include <set>
+#include <string>
+
+#include "base/macros.h"
+#include "base/memory/singleton.h"
+
+class KeepAliveRegistry {
+ public:
+  static KeepAliveRegistry* GetInstance();
+
+  void RegisterToken(const std::string& token);
+  void UnregisterToken(const std::string& token);
+
+ private:
+  friend struct base::DefaultSingletonTraits<KeepAliveRegistry>;
+
+  KeepAliveRegistry();
+  virtual ~KeepAliveRegistry();

[sky, 2016/02/19 21:02:49]

Why the virtual?

[dgn, 2016/02/22 18:01:20]

No subclass involved here, so removed it.

+
+  std::multiset<std::string> registered_tokens_;

[sky, 2016/02/19 21:02:49]

Is there a reason why you aren't using a map<string,int> ? I get that multiset
works, but it's a bit esoteric for this use case.

[dgn, 2016/02/22 18:01:20]

With the int being the number of registered tokens with the same name? For the
optimizations later, I plan to have another multiset for tokens allowing
restart, and comparing the size of the 2 multisets to determine when restart is
safe. That would not work with maps and counts. I would have to maintain a
separate counter or compute it everytime, or do something else to track state

[sky, 2016/02/24 18:53:21]

Couldn't you just as well use two map<enum,int> and compare the sizes? Again, it
doesn't seem to me that you need a multiset here. If it makes sense in the
future, you can always change it, but for the time being a map<enum,int> is more
straightforward.

[dgn, 2016/02/24 19:55:45]

I think we had different assumptions. I started working on a CL with restart
here: https://codereview.chromium.org/1725883002/

I can have the case where the maps would look like:

 registered | restart_allowed
------------+-----------------
  Foo - 1   |   Foo - 1
  Bar - 2   |   Bar - 1


There are 3 keep_alive registered in one and 2 in the other. So the size doesn't
help and I need to sum the ints there.

For this I am assuming that since call site would have control of their options
and they can mix the different options the way they want regardless of the
KeepAliveOrigin value.

If we assume that one KeepAliveOrigin always has a certain set of options that
does not change, then yes, the maps works fine. But then I might as well
centralize all the options and the only thing the caller would ever see would be
the KeepAliveOrigin. I would prefer if that was expressed in the caller's file,
that's the kind of things that seem like they gain at being explicitly present,
for reading the code or reviews...

So in the case where we want to have fixed origin-options combinations, I could
go with maps and structs declared in keep_alive_types (or something like that),
but if we want to let callers register KeepAlives as will, we would go with
multisets and a registration by providing all the options separately?

Did I understand correctly?

[dgn, 2016/02/24 21:04:18]

Done.

+
+  DISALLOW_COPY_AND_ASSIGN(KeepAliveRegistry);
+};
+
+#endif  // CHROME_BROWSER_LIFETIME_KEEP_ALIVE_REGISTRY_H_