diff --git a/src/vault/gear/activity.hpp b/src/vault/gear/activity.hpp index 3fffc5a67..be4c4bd93 100644 --- a/src/vault/gear/activity.hpp +++ b/src/vault/gear/activity.hpp @@ -110,6 +110,35 @@ namespace gear { }; + /** + * Extension point to invoke a callback from Activity activation + * @remark referred from the Activity::Verb::HOOK + * @see ActivityDetector primary usage for testing + */ + class Hook + { + public: + virtual ~Hook(); ///< this is an interface + + /** + * Callback on activation of the corresponding HOOK-Activity. + * @param thisHook the Activity record wired to this hook + * @param executionCtx opaque pointer to the actual execution context + * @param now current »wall-clock-time« as used by the Scheduler + * @return decision how to proceed with the activation + * @remark the intended use is to rig this callback based on additional knowledge + * regarding the usage context. Through \a thisHook, the follow-up chain + * is accessible, and an additional payload data field (`size_t`). Since + * the execution context is a _concept,_ it is necessary to know the actual + * type of the concrete execution context and cast down in the implementation. + * This mechanism is used especially for detecting expected test invocations. + */ + virtual Proc activation ( Activity& thisHook + , void* executionCtx + , Time now) =0; + }; + + /** * Definition to emulate a _Concept_ for the *Execution Context*. * The Execution Context need to be passed to any Activity _activation;_ @@ -161,6 +190,7 @@ namespace gear { ,GATE ///< probe window + count-down; activate next Activity, else re-schedule ,POST ///< post a message providing a chain of further time-bound Activities ,FEED ///< supply additional payload data for a preceding Activity + ,HOOK ///< invoke an _extension point_ through the activity::Hook interface ,TICK ///< internal engine »heart beat« for internal maintenance hook(s) }; @@ -189,6 +219,13 @@ namespace gear { size_t quality; }; + /** Extension point to invoke */ + struct Callback + { + activity::Hook* hook; + size_t arg; + }; + /** Access gate condition to evaluate */ struct Condition { @@ -223,6 +260,7 @@ namespace gear { { Feed feed; Timing timing; + Callback callback; Condition condition; TimeWindow timeWindow; Invocation invocation; @@ -251,6 +289,14 @@ namespace gear { data_.feed.two = o2; } + Activity (JobFunctor& job, Time nominalTime, Activity& feed) noexcept + : Activity{INVOKE} + { + data_.invocation.task = &job; + data_.invocation.time = nominalTime; + next = &feed; + } + explicit Activity (Activity* target) noexcept : Activity{NOTIFY} @@ -280,6 +326,13 @@ namespace gear { data_.timeWindow = {start,after}; } + Activity (activity::Hook& callback, size_t arg) noexcept + : Activity{HOOK} + { + data_.callback.hook = &callback; + data_.callback.arg = arg; + } + Activity() noexcept : Activity{TICK} { } @@ -385,6 +438,14 @@ namespace gear { return executionCtx.post (*next, executionCtx, now); } + template + activity::Proc + callHook (EXE& executionCtx, Time now) + { + return data_.callback.hook? data_.callback.hook->activation(*this, &executionCtx, now) + : activity::PASS; + } + template activity::Proc doTick (EXE& executionCtx, Time now) @@ -417,6 +478,8 @@ namespace gear { return postChain (executionCtx, now); case FEED: return activity::PASS; + case HOOK: + return callHook (executionCtx, now); case TICK: return doTick (executionCtx, now); default: diff --git a/src/vault/gear/scheduler.cpp b/src/vault/gear/scheduler.cpp index dd4748770..66d8cf486 100644 --- a/src/vault/gear/scheduler.cpp +++ b/src/vault/gear/scheduler.cpp @@ -52,7 +52,10 @@ namespace gear { } // internal details - + namespace activity { + + Hook::~Hook() { } // emit VTable here... + } // NA::~NA() { } diff --git a/wiki/renderengine.html b/wiki/renderengine.html index ebb692738..23970e8a3 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -6858,7 +6858,7 @@ At first sight the link between asset and clip-MO is a simple logical relation b {{red{Note 1/2015}}} several aspects regarding the relation of clips and single/multichannel media are not yet settled. There is a preliminary implementation in the code base, but it is not sure yet how multichnnel media will actually be modelled. Currently, we tend to treat the channel multiplicity rather as a property of the involved media, i.e we have //one// clip object. -
+
//Render Activities define the execution language of the render engine.//
 The [[Scheduler]] maintains the ability to perform these Activities, in a time-bound fashion, observing dependency relations; activities allow for notification of completed work, tracking of dependencies, timing measurements, re-scheduling of other activities -- and last but not least the dispatch of actual [[render jobs|RenderJob]]. Activities are what is actually enqueued with priority in the scheduler implementation, they are planned for a »µ-tick slot«, activated once when the activation time is reached, and then forgotten. Each Activity is a //verb//, but can be inhibited by conditions and carry operation object data. Formally, activating an Activity equates to a predication, and the subject of that utterance is »the render process«.
 
@@ -6878,6 +6878,8 @@ The [[Scheduler]] maintains the ability to perform these Activities, in a time-b
 :supply additional payload data for a preceding Activity
 ;post
 :post a message providing a chain of further time-bound Activities
+;hook
+:invoke a callback, passing invocation information. Intended for testing.
 ;tick
 :internal engine »heart beat« -- invoke internal maintenance hook(s)
 
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm
index fca93d175..808ec20c1 100644
--- a/wiki/thinkPad.ichthyo.mm
+++ b/wiki/thinkPad.ichthyo.mm
@@ -78074,6 +78074,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
+
+
 
 
 
@@ -78597,6 +78604,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+
+
+
 
 
 
@@ -81684,6 +81698,21 @@ Date:   Thu Apr 20 18:53:17 2023 +0200

 
 
 
+
+
+
+
+  
+  
+    

+      ...auch wenn's bisher bloß der Test-Unterstützung dient, es ist in jedem Fall gerechtfertigt, einen generischen Erweiterungspunkt zu haben
+    

+  
+
+
+
+
+