crimson/osd: add registry of external handlers of tracking events

This commit intentionally fails the build. It does that to verify
the static assertion on per-op-type lookup of event registry.

The concrete assertion is the one about `ClientRequest` as we
already moved two of its blocker into the new op tracking infra.

Signed-off-by: Radosław Zarzyński <rzarzyns@redhat.com>

diff --git a/src/crimson/common/operation.h b/src/crimson/common/operation.h
index 31ed35ad59fc837600e5f52d1fe4c1a2b911a474..84387356ba76c0f15bebef95c00e91c78a955920 100644 (file)
--- a/src/crimson/common/operation.h
+++ b/src/crimson/common/operation.h
@@ -158,6 +158,21 @@ private:
   virtual const char *get_type_name() const = 0;
 };
 
+// the main template. by default an operation has no extenral
+// event handler (the empty tuple). specializing the template
+// allows to define backends on per-operation-type manner.
+// NOTE: basically this could be a function but C++ disallows
+// differentiating return type among specializations.
+template <class T>
+struct EventBackendRegistry {
+  template <typename...> static constexpr bool always_false = false;
+
+  static std::tuple<> get_backends() {
+    static_assert(always_false<T>, "Registry specialization not found");
+    return {};
+  }
+};
+
 template <class T>
 struct Event {
   T* that() {
@@ -172,6 +187,14 @@ struct Event {
     that()->internal_backend.handle(*that(),
                                     std::forward<OpT>(op),
                                     std::forward<Args>(args)...);
+    // let's call `handle()` for concrete event type from each single
+    // of our backends. the order in the registry matters.
+    std::apply([&, //args=std::forward_as_tuple(std::forward<Args>(args)...),
+               this] (auto... backend) {
+      (..., backend.handle(*that(),
+                           std::forward<OpT>(op),
+                           std::forward<Args>(args)...));
+    }, EventBackendRegistry<std::decay_t<OpT>>::get_backends());
   }
 };