Add support for single sample metrics.

components/metrics/single_value_histograms_factory_impl.cc

+// Copyright 2017 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 "components/metrics/single_value_histograms_factory_impl.h"
+
+namespace metrics {
+
+class SingleValueCountsHistogramImpl : public base::SingleValueCountsHistogram {
+ public:
+  SingleValueCountsHistogramImpl(
+      scoped_refptr<base::SingleThreadTaskRunner> task_runner,
+      mojom::SingleValueCountsHistogramPtr metric)
+      : metric_(std::move(metric)) {
+    // TODO(dalecurtis): Do we need |task_runner| or can SetSample() be called
+    // from any thread?
+  }
+
+  ~SingleValueCountsHistogramImpl() override {
+    // TODO(dalecurtis): Do we need to release |metric_| on |task_runner_| ?
+  }
+
+  void SetSample(base::HistogramBase::Sample sample) override {
+    metric_->SetSample(sample);
+  }
+
+ private:
+  mojom::SingleValueCountsHistogramPtr metric_;
+
+  DISALLOW_COPY_AND_ASSIGN(SingleValueCountsHistogramImpl);
+};
+
+SingleValueHistogramsFactoryImpl::SingleValueHistogramsFactoryImpl(
+    scoped_refptr<base::SingleThreadTaskRunner> task_runner,
+    mojom::SingleValueHistogramsProviderPtr metric_provider)
+    : provider_(std::move(metric_provider)) {
+  // TODO(dalecurtis): Do we actually need |task_runner| here or is the provider
+  // safe to access from any thread since it is created and persists for the

[Ken Rockot(use gerrit already), 2017/04/21 17:40:56]

No, InterfacePtr is not thread-safe.

[DaleCurtis, 2017/04/21 17:44:33]

Thanks, will redo this section to use task_runner, this will cause the Create()
function below to become async unfortunately. Are there any thread-safe mojo
concepts you'd recommend here vs the standard trampoline?

[Ken Rockot(use gerrit already), 2017/04/21 18:03:27]

We'd like a proper thread-safe InterfacePtr, but some of the semantics (e.g.
dispatching replies and error callbacks) are tricky and we don't have one yet.
We do have ThreadSafeInterfacePtr, but it does trampolining anyway and I would
strongly discourage its use in your case. You can just do your own trampolining
and it will likely be less messy.

Another option to consider would be to use thread-local InterfacePtrs. I think
that might be preferable. It's probably cheaper than trampolining.

[DaleCurtis, 2017/04/21 18:18:34]

Can you elaborate on how a TL IP would work? I.e. are you suggesting we only
allow clients to use this from the creating thread? media/ consists of many
threads and the space of base/ clients even more, so the interface does need
thread-safety.

+  // lifetime of the process?
+}
+
+SingleValueHistogramsFactoryImpl::~SingleValueHistogramsFactoryImpl() {
+  // This factory persists until process shutdown.
+  NOTREACHED();
+}
+
+std::unique_ptr<base::SingleValueCountsHistogram>
+SingleValueHistogramsFactoryImpl::CreateSingleValueCountsHistogram(
+    const std::string& name,
+    base::HistogramBase::Sample min,
+    base::HistogramBase::Sample max,
+    uint32_t bucket_count) {
+  mojom::SingleValueCountsHistogramPtr metric;
+  provider_->AcquireSingleValueCountsHistogram(
+      name, min, max, bucket_count,
+      mojo::MakeRequest<mojom::SingleValueCountsHistogram>(&metric));
+  return base::MakeUnique<SingleValueCountsHistogramImpl>(nullptr,
+                                                          std::move(metric));
+}
+
+}  // namespace metrics