Re-land first pass BackgroundTracingManager.

content/public/browser/background_tracing_manager.h

Index: content/public/browser/background_tracing_manager.h
diff --git a/content/public/browser/background_tracing_manager.h b/content/public/browser/background_tracing_manager.h
new file mode 100644
index 0000000000000000000000000000000000000000..2bc86bd386ab9faf50cfe9a187977bcc30c17ad3
--- /dev/null
+++ b/content/public/browser/background_tracing_manager.h
@@ -0,0 +1,58 @@
+// Copyright 2015 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_BACKGROUND_TRACING_MANAGER_H_
+#define CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_MANAGER_H_
+
+#include "base/trace_event/trace_event_impl.h"
+#include "base/values.h"
+#include "content/common/content_export.h"
+
+namespace content {
+struct BackgroundTracingConfig;
+class BackgroundTracingUploadSink;
+
+// BackgroundTracingManager is used on the browser process to trigger the
+// collection of trace data and upload the results. Only the browser UI thread
+// is allowed to interact with the BackgroundTracingManager. All callbacks are
+// called on the UI thread.
+class BackgroundTracingManager {
+ public:
+  CONTENT_EXPORT static BackgroundTracingManager* GetInstance();
+
+  // Set the triggering rules for when to start recording.
+  virtual bool SetActiveScenario(

[no sievers, 2015/05/14 21:25:16]

Question: Do you think it would ever be useful to allow multiple clients (or
rather active scenarios) at the same time?
I'm asking because the behavior is undefined here for the callers - and there
might be multiple that don't know about each other - if there is already an
active scenario.

Either it needs to clobber the old one, or it needs to fail.

At the same time, it doesn't seem too complicated to support multiple callers.
You really only care about whether tracing needs to be enabled (someone is
waiting to finalize a trace *prior* to the event) and what categories need to be
enabled (either it's always the superset or you need to filter depending on the
sink).

I don't feel strongly, but I think you should at least document here what the
behavior is if another scenario is already active.

[shatch, 2015/05/15 21:00:51]

Hmm I'm not sure how easy or useful it would be to support multiple sets of
configs. Maybe reactive mode wouldn't be too bad since you'd just need to merge
in the new rules. Preemptive mode is more complex in that you'd need to either
do as you suggest and do a superset of categories + filtering, or simply fail if
the configs can't be combined.

I'm not sure there's an easy way to "filter" the finalized trace at the moment,
and adding it could be a lot of work. I imagine we'd need to decompress the
finalized trace, parse it to filter out the categories, and then recompress it
before uploading.

I think I'd prefer to go the simple route at the moment and do what
TracingController does, which is support just 1 caller at a time and fail if you
call it again while it's still working. I'll document it a bit more to make it
more clear what the behaviour will be if there's already a config set.

+      scoped_refptr<BackgroundTracingConfig> config,
+      scoped_refptr<BackgroundTracingUploadSink> upload_sink) = 0;
+
+  // Notifies the caller when the manager is idle (not recording or uploading),
+  // so that a call to SetActiveScenario() is likely to succeed.
+  typedef base::Callback<void()> IdleCallback;
+  virtual void WhenIdle(IdleCallback idle_callback) = 0;
+
+  typedef base::Callback<void(bool)> StartedFinalizingCallback;
+  typedef int TriggerHandle;
+
+  // Notifies that a manual trigger event has occurred, and we may need to
+  // either begin recording or finalize the trace, depending on the config.
+  // If the trigger specified isn't active in the config, this will do nothing.
+  virtual void DidTriggerHappen(TriggerHandle,

[no sievers, 2015/05/14 21:25:16]

nit: Maybe avoid the 'Did' prefix here. You are really triggering a trigger :)
And maybe 'event' is a better word for trigger, i.e. TriggerNamedEvent()? Or if
you want to stick with 'trigger' maybe InvokeNamedTrigger() or DoTrigger() or
so?

[shatch, 2015/05/15 21:00:51]

Done.

+                                StartedFinalizingCallback started_callback) = 0;
+
+  // Registers a manual trigger handle, and returns a TriggerHandle which can
+  // be passed to DidTriggerHappen().
+  virtual TriggerHandle RegisterTriggerType(const char* trigger_name) = 0;
+
+  // Returns a list of all registered triggers.
+  virtual void GetTriggerNameList(std::vector<std::string>& trigger_names) = 0;
+
+  virtual void InvalidateTriggerHandlesForTesting() = 0;
+
+ protected:
+  virtual ~BackgroundTracingManager() {}
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_BACKGROUND_TRACING_MANAGER_H_