Created multi-process-friendly PowerMonitor interface.

base/power_monitor/power_monitor.cc

Index: base/power_monitor/power_monitor.cc
diff --git a/base/power_monitor/power_monitor.cc b/base/power_monitor/power_monitor.cc
index 87188f1c591eb1c6a4bdf38bacc4125f045b91bd..19f3ff3a853e0ee63636d02a4c369219df401f8d 100644
--- a/base/power_monitor/power_monitor.cc
+++ b/base/power_monitor/power_monitor.cc
@@ -4,40 +4,30 @@
 
 #include "base/power_monitor/power_monitor.h"
 
-#include "base/time/time.h"
+#include "base/power_monitor/power_monitor_device_source.h"
 
 namespace base {
 
 static PowerMonitor* g_power_monitor = NULL;
 
-#if defined(ENABLE_BATTERY_MONITORING)
-// The amount of time (in ms) to wait before running the initial
-// battery check.
-static int kDelayedBatteryCheckMs = 10 * 1000;
-#endif  // defined(ENABLE_BATTERY_MONITORING)
-
+// This constructor is provided to preserve backwards compatibility with the

[vandebo (ex-Chrome), 2013/07/02 22:53:12]

Hmm, I wonder if we should just change the browser process callsite to construct
the PowerMonitorDeviceSource()... I guess we should leave that for a future
change when all the current uses of the empty constructor are changed.

Add TODO to remove this constructor?

+// most common use case, where the power monitor is created on a UI thread to
+// directly monitor system power events.
 PowerMonitor::PowerMonitor()
     : observers_(new ObserverListThreadSafe<PowerObserver>()),
-      battery_in_use_(false),
-      suspended_(false) {
+      source_(new PowerMonitorDeviceSource()) {
   DCHECK(!g_power_monitor);
   g_power_monitor = this;
+}
 
-  DCHECK(MessageLoop::current());
-#if defined(ENABLE_BATTERY_MONITORING)
-  delayed_battery_check_.Start(FROM_HERE,
-      base::TimeDelta::FromMilliseconds(kDelayedBatteryCheckMs), this,
-      &PowerMonitor::BatteryCheck);
-#endif  // defined(ENABLE_BATTERY_MONITORING)
-#if defined(OS_MACOSX)
-  PlatformInit();
-#endif
+PowerMonitor::PowerMonitor(PowerMonitorSource* source)
+    : observers_(new ObserverListThreadSafe<PowerObserver>()),
+      source_(source) {
+  DCHECK(!g_power_monitor);
+  g_power_monitor = this;
 }
 
 PowerMonitor::~PowerMonitor() {
-#if defined(OS_MACOSX)
-  PlatformDestroy();
-#endif
   DCHECK_EQ(this, g_power_monitor);
   g_power_monitor = NULL;
 }
@@ -55,42 +45,14 @@ void PowerMonitor::RemoveObserver(PowerObserver* obs) {
   observers_->RemoveObserver(obs);
 }
 
-void PowerMonitor::ProcessPowerEvent(PowerEvent event_id) {
-  // Suppress duplicate notifications.  Some platforms may
-  // send multiple notifications of the same event.
-  switch (event_id) {
-    case POWER_STATE_EVENT:
-      {
-        bool on_battery = IsBatteryPower();
-        if (on_battery != battery_in_use_) {
-          battery_in_use_ = on_battery;
-          NotifyPowerStateChange();
-        }
-      }
-      break;
-    case RESUME_EVENT:
-      if (suspended_) {
-        suspended_ = false;
-        NotifyResume();
-      }
-      break;
-    case SUSPEND_EVENT:
-      if (!suspended_) {
-        suspended_ = true;
-        NotifySuspend();
-      }
-      break;
-  }
-}
-
-void PowerMonitor::BatteryCheck() {
-  ProcessPowerEvent(PowerMonitor::POWER_STATE_EVENT);
+PowerMonitorSource* PowerMonitor::Source() {
+  return source_.get();
 }
 
-void PowerMonitor::NotifyPowerStateChange() {
-  DVLOG(1) << "PowerStateChange: " << (BatteryPower() ? "On" : "Off")
+void PowerMonitor::NotifyPowerStateChange(bool battery_in_use) {

[apatrick_chromium, 2013/07/02 19:39:29]

In the browser process, this is invoked on the UI thread because it is called
indirectly from a window message handler (at least on Windows). In the GPU
process, this will be invoked on the IO thread because it is called from a
message filter. As a result, the observers registered with the PowerMonitor will
also run on the IO thread. Is this intentional?

You could have the observers run on the GPU process' main thread by not using a
MessageFilter and instead handling them in GpuChannelManager::OnMessageReceived
or GpuChildThread::OnMessageReceived.

[bajones, 2013/07/02 20:35:26]

I considered just adding the message handlers directly, but it's very likely
that the render process (are there any others?) will want this same behavior.
There's already power monitor code in render process that isn't functioning
correctly, and these changes would help it. By encapsulating the behavior in a
message filter it's trivial to extend the power monitor into new locations. 

[vandebo (ex-Chrome), 2013/07/02 22:53:12]

ObserverListThreadSafe explicitly says it's ok to notify from any thread, so
this seems fine.

+  DVLOG(1) << "PowerStateChange: " << (battery_in_use ? "On" : "Off")
            << " battery";
-  observers_->Notify(&PowerObserver::OnPowerStateChange, BatteryPower());
+  observers_->Notify(&PowerObserver::OnPowerStateChange, battery_in_use);
 }
 
 void PowerMonitor::NotifySuspend() {