Global Resource Coordinator: Basic service internals

services/resource_coordinator/public/cpp/resource_coordinator_interface.h

+// 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.
+
+#ifndef SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_RESOURCE_COORDINATOR_INTERFACE_H_
+#define SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_RESOURCE_COORDINATOR_INTERFACE_H_
+
+#include <stdint.h>
+
+#include "base/macros.h"
+#include "base/memory/weak_ptr.h"
+#include "base/threading/thread_checker.h"
+#include "services/resource_coordinator/public/interfaces/coordination_unit.mojom.h"
+
+namespace service_manager {
+class Connector;
+}
+
+namespace resource_coordinator {
+
+class ResourceCoordinatorInterface {
+ public:
+  ResourceCoordinatorInterface(service_manager::Connector* connector,
+                               const CoordinationUnitType& type);
+  ~ResourceCoordinatorInterface();
+
+  const mojom::CoordinationUnitPtr& service() const { return service_; }
+
+  void SendEvent(const EventType& event_type);
+  void AddChild(const ResourceCoordinatorInterface& child);
+
+ private:
+  void ConnectToService(service_manager::Connector* connector,
+                        const CoordinationUnitType& type,
+                        const std::string& id);
+  void AddChildByID(const CoordinationUnitID& child_id);
+
+  mojom::CoordinationUnitPtr service_;
+
+  base::ThreadChecker thread_checker_;
+
+  // The WeakPtrFactory should come last so the weak ptrs are invalidated

[Primiano Tucci (use gerrit), 2017/04/11 18:04:52]

isn't this the other way round (fiedls in the bottom are constructed last and
destructed first)?
Anyhow feels a bit fragile to depend on the order of fields, why do you need
this at all?
As long as everything happens in the same thread, there should be never a moment
when you see the pointer but not the rest of the struct.
What is the case that makes this guarantee necessary?

[oystein (OOO til 10th of July), 2017/04/12 19:15:31]

I mixed up the wording; the WeakPtrs should be destructed *before* the rest of
the members:
https://cs.chromium.org/webrtc/src/base/memory/weak_ptr.h?q=WeakPtrFactory+sh...

It shouldn't be an issue in this specific case, more of a general
safeguard/habit in case the destruction of the other members end up referring
back to a WeakPtr, I assume (on the same thread).

+  // after the rest of the member variables.
+  base::WeakPtrFactory<ResourceCoordinatorInterface> weak_ptr_factory_;
+
+  DISALLOW_COPY_AND_ASSIGN(ResourceCoordinatorInterface);
+};
+
+}  // namespace resource_coordinator
+
+#endif  // SERVICES_RESOURCE_COORDINATOR_PUBLIC_CPP_RESOURCE_COORDINATOR_INTERFACE_H_