Collect profiler stats from browser child processes.

content/public/browser/profiler_synchronizer.h

Index: content/public/browser/profiler_synchronizer.h
===================================================================
--- content/public/browser/profiler_synchronizer.h	(revision 0)
+++ content/public/browser/profiler_synchronizer.h	(revision 0)
@@ -0,0 +1,23 @@
+// Copyright (c) 2011 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.
+
+#ifndef CONTENT_PUBLIC_BROWSER_PROFILER_SYNCHRONIZER_H_
+#define CONTENT_PUBLIC_BROWSER_PROFILER_SYNCHRONIZER_H_
+#pragma once
+
+#include "content/common/content_export.h"
+
+namespace content {
+
+// Contact all processes and ask them to profiler data. It returns 2 to indicate
+// that ProfilerController's OnPendingProcesses will be called once for renderer
+// processes and another for browser child processes.
+CONTENT_EXPORT int GetProfilerData(int sequence_number);

[jam, 2011/11/28 15:17:34]

just a few general notes about the api:
-it seems that a return value which is always known is not that useful
-it seems easier for the profiler subscribers, and a little cleaner from an API
point of view, if we hide the fact that we have process hosts on different
threads from them (and them having to worry about incrementing/decrementing this
counter). so why not have ProfilerControllerImpl keep the stats from all the
child processes and give it at one time?
-why are these static methods in a separate file, and not part of
ProfilerController? it seems a little confusing that a ProfilerSubscriber has to
register with ProfilerController to receive the updates, but it actually has to
call another method in a different file to get this started

[ramant (doing other things), 2011/11/29 01:32:20]

Didn't want chrome code to know how many type process type iterators there are.
In future if we were to add another process type, thought it is better to hide
those details here.
We wanted to send the data back to UI as soon as we have received it. UI could
display how many processes it is waiting for. Currently UI updates the profiler
page with all the data that is collected every 0.5 secs.
As you had pointed the asynchronous nature doesn't stop the UI from updating
even if one process hasn't responded with the data.
Thanks for the above idea. Deleted this file and moved all the code into
ProfilerController.
Done.

[jam, 2011/11/30 00:22:25]

but it's not hiding it if we tell the embedder this count.

that's why i think it's still much easier, and simpler from an API point of
view, to just call method once with all the data. another possibility is to make
the callback have another parameter, i.e. "bool end", which is set to true the
last time. that way it doesnt have to do the increment business, and we dont
have to give it this magic number.

+
+// Contact all processes and set profiler status to |enable|.
+CONTENT_EXPORT void SetProfilerStatus(bool enable);
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_PROFILER_SYNCHRONIZER_H_
Property changes on: content\public\browser\profiler_synchronizer.h
___________________________________________________________________
Added: svn:executable
   + *