Activity-Lang: instrumentation to make the complete call sequence visible

No new functionality, and implementation works as expected.

This test case covers an especially tricky setup, where a calculation
shall be triggered from an external event, while ensuring that the actual
processing can start only after also the regular time-bound scheduling
has taken place (this might be used to prevent an unexpectedly early
external signal to cause writing into an output buffer before the
defined window of data delivery)
This commit is contained in:
Fischlurch 2023-09-01 23:51:15 +02:00
parent 6563688e07
commit e6d233def2
2 changed files with 194 additions and 132 deletions

View file

@ -472,7 +472,7 @@ namespace test {
Job testJob{detector.buildMockJob("testJob", nominal, 12345)};
TimeVar now = Time{5,5};
detector.executionCtx.getSchedTime = [&]{ // increase "current" time on each access
detector.executionCtx.getSchedTime = [&]{ // increase "current" time on each access
now += FSecs(1,20);
return now;
};
@ -491,18 +491,17 @@ namespace test {
.beforeInvocation("CTX-work").arg("5.155","")
.beforeInvocation("testJob") .arg("7.007",12345)
.beforeInvocation("CTX-done").arg("5.355",""));
cout << detector.showLog()<<endl;
}
/** @test TODO usage scenario: Notification from prerequisite Jobs within time window
/** @test usage scenario: Notification from prerequisite Jobs within time window
* - build [similar](\ref #scenario_RenderJob) »CalculationJob« wiring
* - configure extended dependency notification capabilities
* - Case-1 : a Notification decreases the latch, but blocks otherwise
* - Case-2 : when the primary chain is activated after the Notification,
* then the tail chain behind the Gate is dispatched
* @todo WIP 8/23 🔁 define ✔ implement
* @todo WIP 8/23 ✔ define ✔ implement
*/
void
scenario_Notification()
@ -517,50 +516,70 @@ namespace test {
BlockFlowAlloc bFlow;
ActivityLang activityLang{bFlow};
auto term = activityLang.buildCalculationJob (testJob, start,dead);
Activity& anchor = term.post();
// insert instrumentation to trace activation
detector.watchGate (anchor.next, "theGate");
// establish a blocking prerequisite dependency
// emulate a blocking prerequisite dependency
Activity trigger{Activity::NOTIFY};
// ...in real usage this happens from building the dependency's Term
term.expectNotification (trigger);
// additionally insert inhibition prior to primary-chain activation
term.requireDirectActivation();
// Build the Activity-Term...
auto term = activityLang.buildCalculationJob (testJob, start,dead)
.expectNotification (trigger) // ...require notification from prerequisite
.requireDirectActivation(); // ...additionally insert inhibition to avoid activation
// before the primary-chain has been scheduled
Activity& anchor = term.post();
CHECK (anchor.is (Activity::POST));
CHECK (anchor.next->is (Activity::NOTIFY));
CHECK (anchor.next->next->is (Activity::GATE));
CHECK (anchor.next->next->next->is (Activity::WORKSTART));
CHECK (anchor.next->next->next->next->is (Activity::INVOKE));
CHECK (anchor.next->next->next->next->next->is (Activity::FEED));
CHECK (anchor.next->next->next->next->next->next->is (Activity::FEED));
CHECK (anchor.next->next->next->next->next->next->next->is (Activity::WORKSTOP));
CHECK (anchor.next->next->next->next->next->next->next->next == nullptr);
// insert test-instrumentation to trace activation
detector.watchGate (anchor.next->next, "theGate");
detector.insertActivationTap(trigger.data_.notification.target, "trigger");
detector.insertActivationTap(anchor.next->data_.notification.target, "deBlock");
// rig the λ-post to forward dispatch as expected in real usage
detector.executionCtx.post.implementedAs(
[&](Time when, Activity& postedAct, auto& ctx)
{
if (when == ctx.getSchedTime())
if (when == ctx.getSchedTime()) // only for POST to run „right now“
return activityLang.dispatchChain (postedAct, ctx);
else
return activity::PASS;
});
///// Case-1 : send a notification from prerequisite, but prior to activating primary-chain
CHECK (activity::PASS == ActivityLang::dispatchChain (trigger, detector.executionCtx));
CHECK (detector.verifyInvocation("trigger") .seq(0).arg("5.555 --notify-↯> Act(GATE")
.arg("<2, until 0:00:10.000"));
CHECK (detector.verifyInvocation("trigger") .seq(0).arg("5.555 --notify-↯> Act(GATE") // notification dispatched to the Gate
.arg("<2, until 0:00:10.000")); // Note: the Gate-latch expects 2 notifications
CHECK (detector.ensureNoInvocation("testJob") // ==> the latch was decremented but no invocation yet
.afterInvocation("trigger"));
///// Case-2 : now activate the primary-chain
detector.incrementSeq();
CHECK (activity::PASS == ActivityLang::dispatchChain (anchor, detector.executionCtx));
CHECK (detector.verifyInvocation("CTX-post").seq(1).arg("5.555","Act(NOTIFY","≺test::CTX≻")
.beforeInvocation("after-theGate").seq(1).arg("5.555 ⧐ Act(WORKSTART")
.beforeInvocation("CTX-work").arg("5.555","")
.beforeInvocation("testJob") .arg("7.007",12345)
.beforeInvocation("CTX-done").arg("5.555","")
.beforeInvocation("theGate").seq(1).arg("<0, until -85401592:56:01.825"));
CHECK (detector.verifyInvocation("CTX-post").seq(1).arg("5.555","Act(NOTIFY","≺test::CTX≻") // immediately at begin, the internal self-notification is posted
.beforeInvocation("deBlock") .seq(1).arg("5.555 --notify-↯> Act(GATE") // ...and then dispatched recursively via ActivityLang::dispatchChain() towards the Gate
.arg("<1, until 0:00:10.000") // Note: at this point, the Gate-latch expects 1 notifications
.beforeInvocation("CTX-post").seq(1).arg("5.555","after-theGate","≺test::CTX≻") // ==> the latch was decremented and the Gate OPENS, and thus post() the tail-chain
.beforeInvocation("after-theGate") .arg("5.555 ⧐ Act(WORKSTART") // ...causing the activation to pass behind the Gate
.beforeInvocation("CTX-work").seq(1).arg("5.555","") // ...through WORKSTART
.beforeInvocation("testJob") .seq(1).arg("7.007",12345) // ...then invoke the JobFunctor itself (with the nominal Time{7,7})
.beforeInvocation("CTX-done").seq(1).arg("5.555","") // ...and finally the WORKSTOP
.beforeInvocation("theGate") .seq(1).arg("5.555 ⧐ Act(GATE") // RETURN to the primary-chain activation (after the internal self-notification)
.arg("<0, until -85401592:56:01.825")); // -- however, after opening the Gate, the notification has blocked it permanently
CHECK (detector.ensureNoInvocation("testJob") // ==> thus no further (redundant) activation of the JobFunctor
.afterInvocation("CTX-done").seq(1));
detector.incrementSeq();
CHECK (activity::PASS == ActivityLang::dispatchChain (trigger, detector.executionCtx));
CHECK (detector.verifyInvocation("trigger") .seq(2).arg("5.555 --notify-↯> Act(GATE")
.arg("<0, until -85401592:56:01.825"));
cout << detector.showLog()<<endl;
CHECK (activity::PASS == ActivityLang::dispatchChain (trigger, detector.executionCtx)); // and any further external trigger is likewise blocked:
CHECK (detector.verifyInvocation("trigger") .seq(2).arg("5.555 --notify-↯> Act(GATE") // ... it reaches the Gate
.arg("<0, until -85401592:56:01.825")); // ... but the Gate has been closed permanently (by setting the deadline to Time::MIN)
CHECK (detector.ensureNoInvocation("testJob") // ==> no further invocation
.afterInvocation("trigger").seq(2));
}

View file

@ -65136,9 +65136,7 @@
</node>
<node COLOR="#338800" CREATED="1515975593614" ID="ID_79714950" MODIFIED="1538868845282" TEXT="Technik">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Fr&#252;hjahr 2018 komplett &#252;berarbeitet.
@ -65193,9 +65191,7 @@
<icon BUILTIN="info"/>
<node CREATED="1521081661071" ID="ID_500707872" MODIFIED="1533608414048" TEXT="L&#xf6;sung-1">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
war im Einsatz seit Beginn der Lumiera-Projektes.
@ -65221,9 +65217,7 @@
</node>
<node CREATED="1521081775631" ID="ID_1326847098" MODIFIED="1533608414048" TEXT="L&#xf6;sung-2">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Im Einsatz seit der Behebung des CLang-Problems bis heute (3/2018).
@ -65270,9 +65264,7 @@
<icon BUILTIN="forward"/>
<node CREATED="1521159000968" ID="ID_1381648131" MODIFIED="1521159186533">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
Bei <i>diesem</i>&#160;Wunsch-Profil bleibt nur eine Variante von <b>L&#246;sung-2</b>
@ -65280,9 +65272,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn nur eine dynamische Laufzeit-Factory erm&#246;glicht, <i>jederzeit</i>&#160; den Konstruktionsmodus zu wechseln
@ -65293,9 +65283,7 @@
</node>
<node CREATED="1521159238935" ID="ID_1109622706" MODIFIED="1521159663752" TEXT="Ein Instanz-Pointer ist zwingend notwendig und auch besser">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn nur ein Instanz-Pointer kann umgebogen oder auf NULL zur&#252;ckgesetzt werden.
@ -65337,9 +65325,7 @@
</node>
<node CREATED="1521159870784" ID="ID_1588722588" MODIFIED="1521160019955" TEXT="der Zugang zur DependencyFactory ist stets ein virtueller Funktionsaufruf">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn er mu&#223; komplett generisch sein, und lib/depend.hpp darf keinerlei Kenntnis
@ -65355,9 +65341,7 @@
</node>
<node CREATED="1521160020971" ID="ID_1097297428" MODIFIED="1521160553255" TEXT="Deshalb sollte die Factory konventionell implementiert werden, nicht als Lambda">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn ein Lambda kann in dieser Lage grunds&#228;tzlich keinen optimierungs-Vorteil bringen,
@ -65370,9 +65354,7 @@
</node>
<node CREATED="1521160107759" ID="ID_669924852" MODIFIED="1521239034598" TEXT="Das Konsistenz-Problem ist in Wirklichkeit ein Architekturproblem">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn es l&#228;uft darauf hinaus, da&#223; die Nutzung eines Dienstes zwar <i>on demand</i>&#160;erfolgt,
@ -65428,9 +65410,7 @@
</node>
<node CREATED="1521160832611" ID="ID_1479783938" MODIFIED="1521161094120">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<i>scheidet</i>&#160;f&#252;r unser Nutzungsmuster aus
@ -65438,9 +65418,7 @@
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...denn es bedutet effektiv, da&#223; viele Instanz-Zeiger &quot;herumfliegen&quot;,
@ -65504,9 +65482,7 @@
</node>
<node COLOR="#338800" CREATED="1521208889297" ID="ID_214019029" MODIFIED="1521335434588" TEXT="Lebenszyklus-Koppelung">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...d.h. Service-Zugang wird automatisch geschlossen,
@ -65528,9 +65504,7 @@
<icon BUILTIN="button_cancel"/>
<node CREATED="1521688310369" ID="ID_1697840327" MODIFIED="1521688369496" TEXT="sinnlos">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
sie werden ja sofort ausgewertet, da die Service-Instanz unmittelbar gebaut wird
@ -65598,9 +65572,7 @@
<node CREATED="1521236930715" ID="ID_1673303474" MODIFIED="1521236948604" TEXT="managen alle die Service-Instanz"/>
<node CREATED="1521236972917" ID="ID_513518069" MODIFIED="1521236991993">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<b>aber</b>&#160;Lebenszyklus ist an die Factory gebunden
@ -65669,9 +65641,7 @@
</node>
<node CREATED="1521239466149" ID="ID_178901788" MODIFIED="1521239728744" TEXT="Local schattiert Lebensende">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Folgendes Szenario ignorieren wir:
@ -65759,9 +65729,7 @@
<icon BUILTIN="button_ok"/>
<node CREATED="1521324240124" ID="ID_1099103129" MODIFIED="1521418281285">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
statische Storage ist <i>irgendwie cool</i>
@ -65778,9 +65746,7 @@
</node>
<node CREATED="1521324321601" ID="ID_805959606" MODIFIED="1521418281285" TEXT="Nachteil: Storage ist stets belegt, auch wenn nicht notwendig">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
das gilt im Besonderen f&#252;r eine default-Storage als Singleton.
@ -65815,9 +65781,7 @@
</node>
<node CREATED="1521303869768" ID="ID_712811337" MODIFIED="1521418281286" TEXT="all das w&#xe4;re auch mit Meyers Singleton irgendwie hinzubekommen....">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
...aber dann eben nicht mehr <i>elegant.</i>
@ -65858,9 +65822,7 @@
<node CREATED="1521385787980" ID="ID_81600101" MODIFIED="1521418281286" TEXT="wird vom Compiler wegoptimiert"/>
<node CREATED="1521385795059" ID="ID_1426898485" MODIFIED="1521418281286" TEXT="sofern er Wirkungslosigkeit nachweisen kann...">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Und das h&#228;ngt nur von den Umst&#228;nden ab.
@ -65915,9 +65877,7 @@
<node CREATED="1522557754877" ID="ID_1831893028" MODIFIED="1522557767223" TEXT="das ClassLock wird erst on-demand erzeugt"/>
<node CREATED="1522557767787" ID="ID_405329609" MODIFIED="1522557791751">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
daher <b>mu&#223;</b>&#160;sein dtor <b>vor</b>&#160;dem dtor von DependencyFactory laufen
@ -65940,9 +65900,7 @@
<icon BUILTIN="forward"/>
<node COLOR="#338800" CREATED="1522558005906" ID="ID_1914654214" MODIFIED="1522558192841" TEXT="re-entrance w&#xe4;hrend dem dtor-Aufruf eigens behandeln">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn w&#228;hrend dem dtor existiert das Lock nicht mehr.
@ -66004,9 +65962,7 @@
</node>
<node CREATED="1521696334383" ID="ID_1627167666" MODIFIED="1561827466112" TEXT="gef&#xe4;llt mir nicht wirklich">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
denn nun wird das &quot;singleton&quot; schon ziemlich gehaltlos,
@ -77778,9 +77734,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1693496761812" ID="ID_1871769449" MODIFIED="1693497758267" TEXT="stellt eine bindende Startzeit-Schwelle her">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Falls es eine zeitliche Grenze gibt, vor der die Berechnungen grunds&#228;tzlich nicht starten sollen &#8212; beispielsweise weil die Ergebnis-Daten in einen Puffer geschrieben werden, der erst ab einem bestimmten Zeitpunkt verf&#252;gbar ist; dies wird dann <i>indirekt codiert durch den Start-Zeitpunkt</i>&#160;der Haupt-Berechnung, und das Einschleifen einer Notification auf das direkt nachfolgende Gate, was dazu f&#252;hrt, da&#223; eine extern empfangene Notification von abgeschlossenen Vorg&#228;nger-Berechnungen erst <i>nach diesem Zeitpunkt</i>&#160;das Gate &#246;ffnen k&#246;nnen. Diese interne Freischaltungs-Notification wird direkt hinter dem Ankerpunkt (dem POST) eingeh&#228;ngt, verwendet aber ansonsten die vorhandenen Mechanismen (indirekte Aktivierung &#252;ber den Dispatch-hook)
@ -78169,9 +78123,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1693500048618" ID="ID_756123423" MODIFIED="1693500318044" TEXT="&#xfc;berfl&#xfc;ssig falls externer Trigger ausschlie&#xdf;lich per Notification kommt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
....denn die Implementierung des Notification-Dispatch erkennt, wenn eine Notification das Gate &#246;ffnet, und dispatched in diesem Fall den Chain sofort zur Ausf&#252;hrung und sperrt dann auch das Gate endg&#252;ltig; das bedeutet: wenn die Aktivierung &#252;ber diesen Mechanismus erfolgt, wird ein geplanter re-Trigger niemals zum Zug kommen (sondern dann stets ein bereits gesperrtes Gate vorfinden
@ -78182,9 +78134,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1693500320700" ID="ID_1158823061" MODIFIED="1693501668230">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
entscheidendes Kriterium: <i>was ist der Regelfall?</i>
@ -78252,9 +78202,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1693501711283" ID="ID_1997106163" MODIFIED="1693501726005" TEXT="dekrementiert stets das Latch"/>
<node CREATED="1693501726593" ID="ID_1647318573" MODIFIED="1693501760642">
<richcontent TYPE="NODE"><html>
<head>
</head>
<head/>
<body>
<p>
<b>nur</b>&#160;wenn <b>dadruch</b>&#160;das Latch &#10236; 0 geht
@ -78268,9 +78216,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
<node CREATED="1693501769499" ID="ID_1059675453" MODIFIED="1693501790365" TEXT="Gate endg&#xfc;ltig sperren">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
indem die deadline &#8788; Time::MIN
@ -79079,14 +79025,75 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<node CREATED="1692122369443" ID="ID_142985202" MODIFIED="1692122387124" TEXT="daf&#xfc;r Nachr&#xfc;sten entsprechender Match-Primitive im EventLog notwendig"/>
</node>
</node>
<node COLOR="#338800" CREATED="1693612743373" FOLDED="true" ID="ID_239996870" MODIFIED="1693613050688" TEXT="Erweiterung: eine Fake-Implementierung als &#x3bb; definieren">
<icon BUILTIN="button_ok"/>
<node CREATED="1693612775995" ID="ID_169225587" MODIFIED="1693612809110" TEXT="daf&#xfc;r immer eine std::function mitschleppen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
kann ja normalerweise leer bleiben (es ist ja nur ein Test)
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1689205129709" ID="ID_355308944" MODIFIED="1692370294024" TEXT="Invocation-Activity">
<node COLOR="#338800" CREATED="1693612810167" ID="ID_337568954" MODIFIED="1693612838027" TEXT="dann alternativ entweder den R&#xfc;ckgabewert, oder das Impl-&#x3bb; aufrufen">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1693612850024" ID="ID_1639561917" MODIFIED="1693612875636" TEXT="ItemWrapper erweitern: explizite default-Initialisierung erm&#xf6;glichen">
<icon BUILTIN="button_ok"/>
<node CREATED="1693612878926" ID="ID_412926179" MODIFIED="1693612931276" TEXT="ungef&#xe4;hrlich und hier praktisch">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...weil es eine eigens aufgerufene Funktion ist, die ich auch f&#252;r alle drei Spezialisierungen sinngem&#228;&#223; anders implementieren kann
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1693612886861" ID="ID_1479625274" MODIFIED="1693613042107" TEXT="Problemf&#xe4;lle betrachte ich als Ausnahme">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Ein Problemfall w&#228;re, wenn eine Funktion einen R&#252;ckgabetyp hat, der nicht default-konstruierbar ist. Ja, sowas kommt vor &#8212; aber ich betrachte es hier nun wirklich als die Ausnahme, und es gibt immer noch den Workaround, in einem solchen Fall eben den gew&#252;nschten R&#252;ckgabewert explizit zu setzen (oder gleich die &#955;-Impl zu verwenden).
</p>
</body>
</html></richcontent>
<icon BUILTIN="yes"/>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1689205129709" FOLDED="true" ID="ID_355308944" MODIFIED="1692370294024" TEXT="Invocation-Activity">
<icon BUILTIN="hourglass"/>
<node CREATED="1692370260876" ID="ID_619089820" MODIFIED="1692370280682" TEXT="fertig konfiguriertes Job-Setup">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1692370260876" ID="ID_619089820" MODIFIED="1693613194609" TEXT="fertig konfiguriertes Job-Setup">
<linktarget COLOR="#23a83d" DESTINATION="ID_619089820" ENDARROW="Default" ENDINCLINATION="155;0;" ID="Arrow_ID_1822122758" SOURCE="ID_316011174" STARTARROW="None" STARTINCLINATION="-4;-43;"/>
<icon BUILTIN="info"/>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1692370281681" ID="ID_1343697626" MODIFIED="1692370290936" TEXT="brauchen wir das &#xfc;berhaupt?">
<node COLOR="#435e98" CREATED="1692370281681" ID="ID_1343697626" MODIFIED="1693613157144" TEXT="brauchen wir das &#xfc;berhaupt?">
<icon BUILTIN="help"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1693613083762" ID="ID_138208914" MODIFIED="1693613154657" TEXT="derzeit nicht...">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
bisher gab es nur einen Testfall, und der betraf den ActivityDetector selber
</p>
</body>
</html></richcontent>
<icon BUILTIN="hourglass"/>
</node>
<node COLOR="#338800" CREATED="1693613090833" ID="ID_316011174" MODIFIED="1693613207786" TEXT="aber ein nutzfertiger JobFunktor ist sehr praktisch">
<arrowlink COLOR="#23a83d" DESTINATION="ID_619089820" ENDARROW="Default" ENDINCLINATION="155;0;" ID="Arrow_ID_1822122758" STARTARROW="None" STARTINCLINATION="-4;-43;"/>
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1693613160272" ID="ID_978018832" MODIFIED="1693613169489" TEXT="YAGNI">
<icon BUILTIN="yes"/>
</node>
</node>
</node>
<node COLOR="#338800" CREATED="1689205263970" FOLDED="true" ID="ID_43321196" MODIFIED="1692459862703" TEXT="activationProbe">
@ -79689,9 +79696,7 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="hourglass"/>
<node CREATED="1693502578373" ID="ID_906293868" MODIFIED="1693502622932" TEXT="bisher nur halb gekl&#xe4;rt">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Es ist noch nicht klar, wie die Callbacks von async-IO aufgeschaltet werden
@ -80160,8 +80165,8 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1693502167005" ID="ID_13120904" MODIFIED="1693528495067" TEXT="scenario_Notification">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1693502167005" ID="ID_13120904" MODIFIED="1693616469802" TEXT="scenario_Notification">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1693502193641" ID="ID_970318761" MODIFIED="1693528493228" TEXT="Grundstruktur wie scenario_RenderJob">
<icon BUILTIN="button_ok"/>
</node>
@ -80176,22 +80181,20 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693502289659" ID="ID_1184407673" MODIFIED="1693502335094" TEXT="zwei Testf&#xe4;lle">
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693502296755" ID="ID_917643294" MODIFIED="1693502333791" TEXT="Notification &#x27f9; dekrementiert">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1693502289659" ID="ID_1184407673" MODIFIED="1693612130867" TEXT="zwei Testf&#xe4;lle">
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1693502296755" ID="ID_917643294" MODIFIED="1693612133203" TEXT="Notification &#x27f9; dekrementiert">
<icon BUILTIN="button_ok"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693502312416" ID="ID_1139733627" MODIFIED="1693502333791" TEXT="primary-Chain &#x27f9; dispatch-Chain">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1693502312416" ID="ID_1139733627" MODIFIED="1693612134716" TEXT="primary-Chain &#x27f9; dispatch-Chain">
<icon BUILTIN="button_ok"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693603368706" ID="ID_1497162884" MODIFIED="1693603379725" TEXT="komplette Aufrufkette verifizieren">
<icon BUILTIN="flag-yellow"/>
<node COLOR="#338800" CREATED="1693603368706" ID="ID_1497162884" MODIFIED="1693612136770" TEXT="komplette Aufrufkette verifizieren">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1693603380721" ID="ID_1170059404" MODIFIED="1693603902911" TEXT="geht so nicht, wegen FakeExecutionCtx">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
Im ActivityDetector sind normalerweise die ctx-&#955; als reine Logging-Funktionen implementiert; aber die nun konstruierte Ausf&#252;hrungs-Logik setzt fest darauf, da&#223; ein Aufruf von ctx.post() sofort in einen ActivityLang::dispatchChain() umgesetzt wird <i><font size="2" color="#562275">(allerdings nicht wirklich immer, sondern nur in dem Fall, da&#223; wir das GroomingToken halten und die im post() gegebene Zeit die aktuelle Zeit ist)</font></i>
@ -80202,13 +80205,25 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<arrowlink COLOR="#8f4550" DESTINATION="ID_1373519941" ENDARROW="Default" ENDINCLINATION="-166;-6;" ID="Arrow_ID_1164574930" STARTARROW="None" STARTINCLINATION="191;13;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1693603571349" ID="ID_1256896805" MODIFIED="1693603880201" TEXT="im vorliegenden Testfall k&#xf6;nnte man eigentlich diesen Aufruf durchreichen...">
<node COLOR="#435e98" CREATED="1693603571349" ID="ID_1256896805" MODIFIED="1693612676262" TEXT="im vorliegenden Testfall k&#xf6;nnte man eigentlich diesen Aufruf durchreichen...">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
gemeint ist: den Aufruf von &#955;-post k&#246;nnte man weitergeben an die ActivityLang-Instanz, die im Test-Kontext konstruiert wurde; damit w&#252;rde also die Pr&#252;fung/Steuerung mit dem GroomingToken ausgelassen, aber ansonsten w&#252;rde dann die Aktivierung direkt an ActivityLang::dispatchChain() weitergegeben.
</p>
<p>
</p>
<p>
<b>Wichtige Einschr&#228;nkung</b>: dieses &#187;Durchreichen&#171; darf man nur machen, wenn der post f&#252;r &#8222;jetzt gleich&#8220; ist, d.h. die im post() gegebene Zeit mu&#223; man checken (sonst w&#252;rde z.B. ein geblocktes Gate, das sich in die Zukunft schedulen m&#246;chte, sofort in eine Endlosschleife laufen)
</p>
</body>
</html></richcontent>
<icon BUILTIN="idea"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1693603663534" ID="ID_1373519941" MODIFIED="1693603891817" TEXT="dem steht aber der feste Datentyp entgegen">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<head/>
<body>
<p>
<font color="#7b4438" face="Monospaced">FakeExecutionCtx</font>&#160;bzw. die dort verwendete <font color="#7b4438" face="Monospaced">DiagnosticFun</font>, auf die man ja tats&#228;chlich zugreifen k&#246;nnen sollte (um den R&#252;ckgabewert zu manipulieren) &#8212; und das w&#228;re bei einer <font face="Monospaced" color="#2f1687">std::function</font>&#160; nicht mehr m&#246;glich...
@ -80226,6 +80241,34 @@ Date:&#160;&#160;&#160;Thu Apr 20 18:53:17 2023 +0200<br/>
<icon BUILTIN="yes"/>
</node>
</node>
<node COLOR="#338800" CREATED="1693612143280" ID="ID_1378873696" MODIFIED="1693612186089" TEXT="lokales &#x3bb; im Test &#x27fc; die Test-Instanz ActivityLang &#x27fc; dispatch()">
<icon BUILTIN="button_ok"/>
</node>
<node COLOR="#338800" CREATED="1693612196689" ID="ID_809138083" MODIFIED="1693612262606" TEXT="JobFunctor bereits direkt &#xfc;ber die Notification aus dem primary-Chain getriggert">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1693612272319" ID="ID_319335391" MODIFIED="1693612445592" TEXT="das vorher beobachtete Verhalten war auch korrekt">
<icon BUILTIN="idea"/>
</node>
<node COLOR="#435e98" CREATED="1693612282669" ID="ID_1612788145" MODIFIED="1693612445592" TEXT="aber so ist der Ablauf wie intendiert">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
<u>Testfall-1</u>:
</p>
<p>
notification &#10236; decr(Gate) &#10236; &#10007;
</p>
<p>
<u>Testfall-2</u>:
</p>
<p>
primary-chain &#10236; notify an Gate &#10236; &#955;-post &#10236; dispatch &#10236; decr(gate) &#10236; PASS &#10236; Rest der Kette
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1689200553782" ID="ID_1346681233" MODIFIED="1689200586861" TEXT="scenario_IOJob">