Created multi-process-friendly PowerMonitor interface.

base/power_monitor/power_monitor.cc

 // Copyright 2013 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/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;
 }
 
 // static
 PowerMonitor* PowerMonitor::Get() {
   return g_power_monitor;
 }
 
 void PowerMonitor::AddObserver(PowerObserver* obs) {
   observers_->AddObserver(obs);
 }
 
 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;
-  }
+PowerMonitorSource* PowerMonitor::Source() {
+  return source_.get();
 }
 
-void PowerMonitor::BatteryCheck() {
-  ProcessPowerEvent(PowerMonitor::POWER_STATE_EVENT);
-}
-
-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() {
   DVLOG(1) << "Power Suspending";
   observers_->Notify(&PowerObserver::OnSuspend);
 }
 
 void PowerMonitor::NotifyResume() {
   DVLOG(1) << "Power Resuming";
   observers_->Notify(&PowerObserver::OnResume);
 }
 
 }  // namespace base