Created multi-process-friendly PowerMonitor interface.

content/browser/power_monitor_message_broadcaster.cc

Index: content/browser/power_monitor_message_broadcaster.cc
diff --git a/content/browser/power_monitor_message_broadcaster.cc b/content/browser/power_monitor_message_broadcaster.cc
new file mode 100644
index 0000000000000000000000000000000000000000..519445be58b08e6188f7a77f54eb414b64b6372f
--- /dev/null
+++ b/content/browser/power_monitor_message_broadcaster.cc
@@ -0,0 +1,87 @@
+// 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 "content/browser/power_monitor_message_broadcaster.h"
+
+#include "base/power_monitor/power_monitor.h"
+#include "content/common/power_monitor_messages.h"
+#include "ipc/ipc_sender.h"
+
+namespace content {
+
+PowerMonitorMessageFilter::PowerMonitorMessageFilter() {
+  BrowserThread::PostTask(
+      BrowserThread::UI,
+      FROM_HERE,
+      base::Bind(
+          &PowerMonitorMessageFilter::CreateBroadcaster,
+          base::Unretained(this)));

[piman, 2013/07/29 21:18:18]

What prevents the filter from being destroyed before this executes on the UI
thread?

+}
+
+PowerMonitorMessageFilter::~PowerMonitorMessageFilter() {
+}
+
+void PowerMonitorMessageFilter::OnChannelClosing() {
+  BrowserMessageFilter::OnChannelClosing();
+
+  BrowserThread::PostTask(
+      BrowserThread::UI,
+      FROM_HERE,
+      base::Bind(
+          &PowerMonitorMessageFilter::DisableBroadcaster,
+          base::Unretained(this)));

[piman, 2013/07/29 21:18:18]

What prevents the filter from being destroyed before this executes on the UI
thread?

[bajones, 2013/07/29 21:33:36]

I'll switch this and the prior post task over to pass a weak reference.

[piman, 2013/07/29 21:40:50]

That won't work.
WeakPtrs are only safe if the instance is deleted on the same thread as where
it's dereferenced.
In this case PowerMonitorMessageFilter will (likely) be deleted on the IO
thread, and you'll need to dereference the weakptr on the UI thread.

Also, you still have the issue that PowerMonitorMessageBroadcaster may try to
access sender_ from the UI thread, and you have no way to ensure it's not
deleted.

+}
+
+bool PowerMonitorMessageFilter::OnMessageReceived(
+      const IPC::Message& message,
+      bool* message_was_ok) {
+  return false; // No messages to handle
+}
+
+void PowerMonitorMessageFilter::CreateBroadcaster() {
+  broadcaster_ = new PowerMonitorMessageBroadcaster(this);
+}
+
+void PowerMonitorMessageFilter::DisableBroadcaster() {
+  broadcaster_->RemoveSender();
+}
+
+PowerMonitorMessageBroadcaster::PowerMonitorMessageBroadcaster(
+    IPC::Sender* sender)
+    : sender_(sender) {
+  base::PowerMonitor* power_monitor = base::PowerMonitor::Get();
+  if (power_monitor)
+    power_monitor->AddObserver(this);
+}
+
+PowerMonitorMessageBroadcaster::~PowerMonitorMessageBroadcaster() {
+  base::PowerMonitor* power_monitor = base::PowerMonitor::Get();
+  if (power_monitor)
+    power_monitor->RemoveObserver(this);

[piman, 2013/07/29 21:18:18]

Because this class is refcounted, it may be destroyed on a different thread
(e.g. IO thread since the PowerMonitorMessageFilter probably has the last
reference) than the one that created it (the UI thread).
Calling RemoveObserver from a different thread than the one that called
AddObserver isn't supported (it would be racy anyway).

[bajones, 2013/07/29 21:33:36]

Please see the class declaration. The RefCountedThreadSafe superclass is
declared with a BrowserThread::DeleteOnUIThread deleter.

+}
+
+void PowerMonitorMessageBroadcaster::RemoveSender() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  sender_ = NULL;
+}
+
+void PowerMonitorMessageBroadcaster::OnPowerStateChange(bool on_battery_power) {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  if (sender_)
+    sender_->Send(new PowerMonitorMsg_PowerStateChange(on_battery_power));

[piman, 2013/07/29 21:18:18]

This is unsafe: sender_ is the message filter, which can only send from the IO
thread.

[bajones, 2013/07/29 21:33:36]

I just realized that by allowing the constructor to take any IPC::Sender I can't
enforce this in the current code, but the current uses of this should be safe.
There are only two senders that are provided to this class currently: The
RenderProcessHostImpl, which is explicitly lives on the UI thread, and the
PowerMonitorMessageFilter, which derives from a BrowserMessageFilter which
explicitly states that it's Send can be called from any thread.

I should change the constructor to make this more explicit, though. It may be
sufficient to create to constructors that take in the aforementioned classes
explicitly.

+}
+
+void PowerMonitorMessageBroadcaster::OnSuspend() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  if (sender_)
+    sender_->Send(new PowerMonitorMsg_Suspend());
+}
+
+void PowerMonitorMessageBroadcaster::OnResume() {
+  DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
+  if (sender_)
+    sender_->Send(new PowerMonitorMsg_Resume());
+}
+
+}  // namespace content