Created multi-process-friendly PowerMonitor interface.

content/gpu/gpu_main.cc

Index: content/gpu/gpu_main.cc
diff --git a/content/gpu/gpu_main.cc b/content/gpu/gpu_main.cc
index 794617dde93681fba6c84b4bba9635e1cf178bbc..7635cf3358d6944fa7e29b1b7e6dfc79058874ee 100644
--- a/content/gpu/gpu_main.cc
+++ b/content/gpu/gpu_main.cc
@@ -19,6 +19,7 @@
 #include "content/child/child_process.h"
 #include "content/common/gpu/gpu_config.h"
 #include "content/common/gpu/gpu_messages.h"
+#include "content/common/power_monitor_client.h"
 #include "content/common/sandbox_linux.h"
 #include "content/gpu/gpu_child_thread.h"
 #include "content/gpu/gpu_process.h"
@@ -169,6 +170,7 @@ int GpuMain(const MainFunctionParams& parameters) {
   delayed_watchdog_enable = true;
 #endif
 
+  PowerMonitorClient power_monitor;

[Ken Russell (switch to Gerrit), 2013/06/24 22:54:38]

I don't think this function should stack-allocate a PowerMonitorClient instance.
If necessary, the PowerMonitorClient can be fetched and initialized here for use
elsewhere, but the PowerMonitorClient singleton should manage its own lifetime.
(If necessary, a Shutdown() method can be added to PowerMonitorClient to eagerly
terminate it and delete the singleton.)

[bajones, 2013/06/25 18:33:34]

While my gut reaction is to agree with you, this is actually a well established
pattern for use of the PowerMonitor. (See
https://code.google.com/p/chromium/codesearch#search/&q=base::PowerMonitor%20...).

   scoped_refptr<GpuWatchdogThread> watchdog_thread;
 
   // Start the GPU watchdog only after anything that is expected to be time