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:
parent
6563688e07
commit
e6d233def2
2 changed files with 194 additions and 132 deletions
|
|
@ -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));
|
||||
}
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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ühjahr 2018 komplett überarbeitet.
|
||||
|
|
@ -65193,9 +65191,7 @@
|
|||
<icon BUILTIN="info"/>
|
||||
<node CREATED="1521081661071" ID="ID_500707872" MODIFIED="1533608414048" TEXT="Lö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ö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> Wunsch-Profil bleibt nur eine Variante von <b>Lö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öglicht, <i>jederzeit</i>  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ü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ß 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ä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äuft darauf hinaus, daß die Nutzung eines Dienstes zwar <i>on demand</i> 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> fü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ß viele Instanz-Zeiger "herumfliegen",
|
||||
|
|
@ -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> 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ür eine default-Storage als Singleton.
|
||||
|
|
@ -65815,9 +65781,7 @@
|
|||
</node>
|
||||
<node CREATED="1521303869768" ID="ID_712811337" MODIFIED="1521418281286" TEXT="all das wä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ängt nur von den Umstä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ß</b> sein dtor <b>vor</b> 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ährend dem dtor-Aufruf eigens behandeln">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn während dem dtor existiert das Lock nicht mehr.
|
||||
|
|
@ -66004,9 +65962,7 @@
|
|||
</node>
|
||||
<node CREATED="1521696334383" ID="ID_1627167666" MODIFIED="1561827466112" TEXT="gefällt mir nicht wirklich">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn nun wird das "singleton" schon ziemlich gehaltlos,
|
||||
|
|
@ -77778,9 +77734,7 @@ Date:   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ätzlich nicht starten sollen — beispielsweise weil die Ergebnis-Daten in einen Puffer geschrieben werden, der erst ab einem bestimmten Zeitpunkt verfügbar ist; dies wird dann <i>indirekt codiert durch den Start-Zeitpunkt</i> der Haupt-Berechnung, und das Einschleifen einer Notification auf das direkt nachfolgende Gate, was dazu führt, daß eine extern empfangene Notification von abgeschlossenen Vorgänger-Berechnungen erst <i>nach diesem Zeitpunkt</i> das Gate öffnen können. Diese interne Freischaltungs-Notification wird direkt hinter dem Ankerpunkt (dem POST) eingehängt, verwendet aber ansonsten die vorhandenen Mechanismen (indirekte Aktivierung über den Dispatch-hook)
|
||||
|
|
@ -78169,9 +78123,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node CREATED="1693500048618" ID="ID_756123423" MODIFIED="1693500318044" TEXT="überflüssig falls externer Trigger ausschließ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 öffnet, und dispatched in diesem Fall den Chain sofort zur Ausführung und sperrt dann auch das Gate endgültig; das bedeutet: wenn die Aktivierung ü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:   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:   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> wenn <b>dadruch</b> das Latch ⟼ 0 geht
|
||||
|
|
@ -78268,9 +78216,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
</node>
|
||||
<node CREATED="1693501769499" ID="ID_1059675453" MODIFIED="1693501790365" TEXT="Gate endgültig sperren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
indem die deadline ≔ Time::MIN
|
||||
|
|
@ -79079,14 +79025,75 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1692122369443" ID="ID_142985202" MODIFIED="1692122387124" TEXT="dafür Nachrü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 λ definieren">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1693612775995" ID="ID_169225587" MODIFIED="1693612809110" TEXT="dafü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ückgabewert, oder das Impl-λ aufrufen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1693612850024" ID="ID_1639561917" MODIFIED="1693612875636" TEXT="ItemWrapper erweitern: explizite default-Initialisierung ermöglichen">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1693612878926" ID="ID_412926179" MODIFIED="1693612931276" TEXT="ungefährlich und hier praktisch">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...weil es eine eigens aufgerufene Funktion ist, die ich auch für alle drei Spezialisierungen sinngemäß anders implementieren kann
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1693612886861" ID="ID_1479625274" MODIFIED="1693613042107" TEXT="Problemfälle betrachte ich als Ausnahme">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Ein Problemfall wäre, wenn eine Funktion einen Rückgabetyp hat, der nicht default-konstruierbar ist. Ja, sowas kommt vor — aber ich betrachte es hier nun wirklich als die Ausnahme, und es gibt immer noch den Workaround, in einem solchen Fall eben den gewünschten Rückgabewert explizit zu setzen (oder gleich die λ-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 überhaupt?">
|
||||
<node COLOR="#435e98" CREATED="1692370281681" ID="ID_1343697626" MODIFIED="1693613157144" TEXT="brauchen wir das ü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:   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ä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:   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:   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älle">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693502296755" ID="ID_917643294" MODIFIED="1693502333791" TEXT="Notification ⟹ dekrementiert">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1693502289659" ID="ID_1184407673" MODIFIED="1693612130867" TEXT="zwei Testfälle">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node COLOR="#338800" CREATED="1693502296755" ID="ID_917643294" MODIFIED="1693612133203" TEXT="Notification ⟹ dekrementiert">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1693502312416" ID="ID_1139733627" MODIFIED="1693502333791" TEXT="primary-Chain ⟹ dispatch-Chain">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node COLOR="#338800" CREATED="1693502312416" ID="ID_1139733627" MODIFIED="1693612134716" TEXT="primary-Chain ⟹ 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-λ als reine Logging-Funktionen implementiert; aber die nun konstruierte Ausführungs-Logik setzt fest darauf, daß 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ß wir das GroomingToken halten und die im post() gegebene Zeit die aktuelle Zeit ist)</font></i>
|
||||
|
|
@ -80202,13 +80205,25 @@ Date:   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önnte man eigentlich diesen Aufruf durchreichen...">
|
||||
<node COLOR="#435e98" CREATED="1693603571349" ID="ID_1256896805" MODIFIED="1693612676262" TEXT="im vorliegenden Testfall könnte man eigentlich diesen Aufruf durchreichen...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
gemeint ist: den Aufruf von λ-post könnte man weitergeben an die ActivityLang-Instanz, die im Test-Kontext konstruiert wurde; damit würde also die Prüfung/Steuerung mit dem GroomingToken ausgelassen, aber ansonsten würde dann die Aktivierung direkt an ActivityLang::dispatchChain() weitergegeben.
|
||||
</p>
|
||||
<p>
|
||||
|
||||
</p>
|
||||
<p>
|
||||
<b>Wichtige Einschränkung</b>: dieses »Durchreichen« darf man nur machen, wenn der post für „jetzt gleich“ ist, d.h. die im post() gegebene Zeit muß man checken (sonst würde z.B. ein geblocktes Gate, das sich in die Zukunft schedulen mö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> bzw. die dort verwendete <font color="#7b4438" face="Monospaced">DiagnosticFun</font>, auf die man ja tatsächlich zugreifen können sollte (um den Rückgabewert zu manipulieren) — und das wäre bei einer <font face="Monospaced" color="#2f1687">std::function</font>  nicht mehr möglich...
|
||||
|
|
@ -80226,6 +80241,34 @@ Date:   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 λ im Test ⟼ die Test-Instanz ActivityLang ⟼ dispatch()">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
</node>
|
||||
<node COLOR="#338800" CREATED="1693612196689" ID="ID_809138083" MODIFIED="1693612262606" TEXT="JobFunctor bereits direkt ü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 ⟼ decr(Gate) ⟼ ✗
|
||||
</p>
|
||||
<p>
|
||||
<u>Testfall-2</u>:
|
||||
</p>
|
||||
<p>
|
||||
primary-chain ⟼ notify an Gate ⟼ λ-post ⟼ dispatch ⟼ decr(gate) ⟼ PASS ⟼ 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">
|
||||
|
|
|
|||
Loading…
Reference in a new issue