Created multi-process-friendly PowerMonitor interface.

content/browser/gpu/gpu_process_host_ui_shim.cc

 // Copyright (c) 2012 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/gpu/gpu_process_host_ui_shim.h"
 
 #include <algorithm>
 
 #include "base/bind.h"
 #include "base/command_line.h"
@@ skipping 85 matching lines @@
 }
 
 }  // namespace
 
 void RouteToGpuProcessHostUIShimTask(int host_id, const IPC::Message& msg) {
   GpuProcessHostUIShim* ui_shim = GpuProcessHostUIShim::FromID(host_id);
   if (ui_shim)
     ui_shim->OnMessageReceived(msg);
 }
 
-GpuProcessHostUIShim::GpuProcessHostUIShim(int host_id)
+GpuProcessHostUIShim::GpuProcessHostUIShim(int host_id, bool single_process)
     : host_id_(host_id) {
   g_hosts_by_id.Pointer()->AddWithID(this, host_id_);
+  if (!single_process)
+    power_monitor_broadcaster_.reset(new PowerMonitorMessageBroadcaster(this));

[jam, 2013/07/17 00:29:42]

since this is a generic class, it should be attached to
BrowserChildProcessHostImpl and to RenderProcessHostImpl. that way it'll work
for all child processes.

see TraceMessageFilter, ProfilerMessageFilter, HistogramMessageFilter etc as
examples

[bajones, 2013/07/19 22:44:56]

I generally agree with this sentiment, but as apatrick pointed out earlier on
(comment #15) the power monitor notifications are created on the UI thread and
thus should be handled there, but the BrowserChildProcessHostImpl is created on
the IO thread. As such it seems to me that the current location in the
GpuProcessHostUIShim is more appropriate (RenderProcessHostImpl is UI thread, so
that should be okay.) Thoughts?

[jam, 2013/07/20 00:28:55]

There are two kinds of child process hosts: the renderer one lives on the UI
thread, and all the other process live on the IO thread. If you just do RPHImpl
and GPUProcessHostUIShim, then these power messages won't be responded to for
all non-renderer and non-gpu child processes. It would be confusing to have such
an API which doesn't work in other processes.

If you create a message filter (like the above examples), you can make it
internally register ot the power notifications on the UI thread. one way to do
this would be to have a refcounted inner class which is owned by the filter. at
construction of the filter, it creates the inner class. in the inner class's
constructor, it posts a task to the UI thread to do the necessary registration.
It can use the DeleteOnUIThread trait to ensure it's destructed on the UI
thread. when the filter goes away, its release of the inner class will make it
destroy on the UI thread, and it can unregister there. the inner class can hold
on to a naked pointer to the filter, which is only accessed on the IO thread, to
send IPCs. the filter can null it out on the IO thread when it gets
OnChannelClosing()

 }
 
 // static
-GpuProcessHostUIShim* GpuProcessHostUIShim::Create(int host_id) {
+GpuProcessHostUIShim* GpuProcessHostUIShim::Create(
+    int host_id,
+    bool single_process) {
   DCHECK(!FromID(host_id));
-  return new GpuProcessHostUIShim(host_id);
+  return new GpuProcessHostUIShim(host_id, single_process);
 }
 
 // static
 void GpuProcessHostUIShim::Destroy(int host_id, const std::string& message) {
   DCHECK(BrowserThread::CurrentlyOn(BrowserThread::UI));
 
   GpuDataManagerImpl::GetInstance()->AddLogMessage(
       logging::LOG_ERROR, "GpuProcessHostUIShim",
       message);
 
@@ skipping 268 matching lines @@
   view->AcceleratedSurfaceRelease();
 }
 
 void GpuProcessHostUIShim::OnVideoMemoryUsageStatsReceived(
     const GPUVideoMemoryUsageStats& video_memory_usage_stats) {
   GpuDataManagerImpl::GetInstance()->UpdateVideoMemoryUsageStats(
       video_memory_usage_stats);
 }
 
 }  // namespace content