From a4ff2081b97ae814c45206d766f92c41b0e0ba7f Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 30 Jul 2024 20:05:48 +0200 Subject: [PATCH] Invocation: explore variants to pass output connection There might be one specific output result buffer at top level for each invocation, which must be delivered into a prepared output sink. This amounts to one special case, cross-cutting an otherwise completely generic data flow scheme. After considering several solutions, it seems most straight-forward to configure a specific `OutputBufferProvider` to serve as a proxy for the `OutputSlot` / `DataSink` provided at top-level to the Render-Job. As an asside, this analyis reveals that the result-slot number does not belong into the `FeedManifold`, which is dynamic (on the stack); rather, it's a fixed value configured as part of the `WeavingPattern` --- src/steam/engine/feed-manifold.hpp | 9 - src/steam/engine/turnout.hpp | 10 +- wiki/thinkPad.ichthyo.mm | 283 +++++++++++++++++++++-------- 3 files changed, 211 insertions(+), 91 deletions(-) diff --git a/src/steam/engine/feed-manifold.hpp b/src/steam/engine/feed-manifold.hpp index 086d209b7..9bdfc92e5 100644 --- a/src/steam/engine/feed-manifold.hpp +++ b/src/steam/engine/feed-manifold.hpp @@ -73,15 +73,6 @@ namespace engine { BuffS inBuff; BuffS outBuff; - - uint resultSlot{0}; - - BuffHandle - result() const - { - ENSURE (resultSlot < N, "invalid result buffer retrieved."); - return outBuff[resultSlot]; - } }; diff --git a/src/steam/engine/turnout.hpp b/src/steam/engine/turnout.hpp index b181362bc..43ac45c57 100644 --- a/src/steam/engine/turnout.hpp +++ b/src/steam/engine/turnout.hpp @@ -415,6 +415,8 @@ namespace engine { Several leadPort; Several outTypes; + uint resultSlot{0}; + //////////////////////////////////////////OOO builder must set-up those descriptors SimpleWeavingPattern(Several&& pr, Several dr) : CONF{} @@ -456,7 +458,7 @@ namespace engine { feed.invoke(); } - void + BuffHandle fix (Feed& feed) { for (uint i=0; i - - - +

Stock-IDs sind @deprecated @@ -5051,9 +5049,7 @@ - - - +

Aufgabe: populate timeline @@ -5269,9 +5265,7 @@ - - - +

»der Viewer« @@ -5459,9 +5453,7 @@ - - - +

Inkscape wendet Transformationen normalerweise nur auf Blatt-Elemente direkt an; sonst fügt es ein "transform"-Element ein; dieses ist eine Matrix für homogene Koordinaten. @@ -5471,9 +5463,7 @@ - - - +

wenn man den Filter entfernt / auf Null dreht (Blur), dann wendet Inkscape die Transformation an @@ -6262,9 +6252,7 @@ - - - +

wenn die GTK-Loop angehalten wird, @@ -8014,9 +8002,7 @@ - - - +

der Resolver macht kein Memory-Management, @@ -10882,9 +10868,7 @@ - - - +

vorgegebene Zahlenfolge
in untendlichem Zufalls-Baum finden @@ -15046,9 +15030,7 @@ - - - +

....jaaaaa, das ist verschwenderisch @@ -22258,9 +22240,7 @@ - - - +

....durch den Versuch, "die Hooks" zu einem allgemeinem Gui-Konstruktionsframework mit double-Dispatch auszubauen, habe ich das bestehende Design erheblich geschärft, und für einige Teilaspekte viel sinnigere Lösungen gefunden. Am Ende hat sich gezeigt, daß meine Vision nicht realisierbar ist, und zwar fehlte eigentlich nur "eine ganz kleine Lücke" ― aber ich bin erfahren genug, um zu wissen, daß man eine solche Situation nicht durch Zaubertricks retten kann. Daher habe ich diese Vision in aller Form begraben, aber die Design-Verbesserungen entsprechend heruntergestuft und so erhalten. @@ -52073,9 +52053,7 @@ - - - +

SessionCommandService::bindArg @@ -52087,9 +52065,7 @@ - - - +

SessionCommandService::invoke @@ -52121,9 +52097,7 @@ - - - +

managed diese Komponente nicht @@ -52149,9 +52123,7 @@ - - - +

aufwendiges Nebenthema @@ -52177,9 +52149,7 @@ - - - +

...das war der erste Entwurf @@ -52219,9 +52189,7 @@ - - - +

Symbol ADD_CLIP = CmdAccess::to (cmd::scope_addClip, INTO_FORK); @@ -52258,9 +52226,7 @@ - - - +

die DSL muß so konstruiert werden, @@ -52288,9 +52254,7 @@ - - - +

(Anmerkung 2/2021) @@ -52388,9 +52352,7 @@ - - - +

...stattdessen einen Fehler-Indikator auslösen @@ -52403,9 +52365,7 @@ - - - +

...das ist eine Reaktion, @@ -85918,10 +85878,12 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + + @@ -88540,6 +88502,13 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + @@ -88637,8 +88606,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + + @@ -88731,7 +88701,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -88739,9 +88710,9 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + - + @@ -88751,15 +88722,20 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + - + + + + + + - + @@ -88769,13 +88745,14 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - + - + + @@ -88788,8 +88765,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...da mit jedem Buffer-Typ auch eine bestimmte Memory-Block-Größe verbunden ist, könnte man dahinter mehrere kachelnde Basis-Allokatoren anordnen — und in einer solchen Struktur wäre es sinnvoll, zu erwartende Buffer-Allokationen im Voraus anzukündigen. Die Steuerung der Pool-Größe könnte dann im Hintergrund erfolgen, was möglicherweise eine relevante Optimierung auf Durchsatz ermöglicht

- - + @@ -88804,8 +88780,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
anhand der Hash-ID, die zum Entry gehört, welcher beim Erzeugen des Handles gespeichert wurde

- - + @@ -88822,8 +88797,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
der Entry wird aus der Metadaten-Tabelle gelöscht

- - + @@ -88843,23 +88817,136 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + + - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...sie entsteht dadurch, daß beide auf bewährten Lösungsmustern aufbauen; das heißt aber noch nicht, daß beide eine gemeinsame Natur haben +

+ + + + + + + + + + +

+ In beiden Fällen gibt es das Problem der Freigabe — aber meine Bewertung ist unterschiedlich ausgefallen: für einen Ausgabe-Vorgang gibt es verschiedene kritische Zustände, und die Möglichkeit einer Verklemmung; und genau weil man den Protokoll-Status über ein Timeout bestimmen kann, besteht auch die Gefahr, daß ein verspäteter Rechenprozeß in Verletzung des Protokolls weiterhin in die Ausgabe schreibt. Ganz anders beim BuffHandle, welches eine möglichst leichtgewichtige low-level-Abstraktion darstellt; die Methoden am dem Handle dienen nur dazu, Protokoll-Schritte auf eine höhere Ebene zurückzumelden, aber der Gebrauch des Handles wird nicht selber durch ein Protokoll geregelt. Hinzu kommt, daß ref-counting einen gewissen Performance-Overhead hat, der für ein BuffHandle vielleicht schon kritisch werden könnte; eine DataSink dagegen wird auf top-Level erstellt und wird dann nach unten nur ausgeliehen +

+ + + + + + + + + + +

+ Das ist das wichtigste Argument: sie finden auf verschiedenen Abstraktionsebenen statt. Der Ausgabevorgang kann möglicherweise  eine Buffer-Verwendung mit einschließen — letztere bekommt aber nur durch den Kontext ihre Bedeutung +

+ + + + + + + + + + + @@ -88882,6 +88969,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + @@ -88890,6 +88987,30 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + + + + + + + + + + + + + + + @@ -137210,6 +137331,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + +