diff --git a/src/steam/engine/buffer-proxy-provider.hpp b/src/steam/engine/buffer-proxy-provider.hpp index e74877c1b..4b724f242 100644 --- a/src/steam/engine/buffer-proxy-provider.hpp +++ b/src/steam/engine/buffer-proxy-provider.hpp @@ -15,7 +15,7 @@ ** Adapter to expose a given memory block through a BuffHandle. ** This allows to integrate a specific data access (e.g. related to input / output) ** with the buffer lifecycle protocol as defined by BufferProvider. - ** @see state.hpp + ** @todo BROKEN as of 12/2024 //////////////////////////////////////////////////////////////////////////////TICKET #1387 : can not properly compose BufferProvider ** @see output-slot.hpp */ @@ -54,21 +54,64 @@ namespace engine { * @todo WIP-WIP 12/2024 this is a design sketch to explore extension capabilities of BufferProvider */ class BufferProxyProvider - : util::MoveOnly + : util::NonCopyable { - std::function listener_; + using Listener = std::function; + + class ForwardingBufferProvider + : public BufferProvider + { + Listener listener_; + + /* === BufferProvider API === */ + + uint + prepareBuffers (uint, HashVal) override + { + NOTREACHED ("this part of the API should not be used"); + return 1; // can not sensibly do anything for "pre-allocation", + } // other than telling the caller that we only "have one buffer to provide" + + BuffHandle + provideLockedBuffer (HashVal typeID) override + { + /////////////////////////////////////////////////////////////////////////////////////TICKET #1387 : BufferProvider default impl. is lacking means to compose and delegate +// return buildHandle (typeID, asBuffer(newBlock.accessMemory()), &newBlock); + } + + void + mark_emitted (HashVal, LocalTag const&) override + { + + } + + void + detachBuffer (HashVal, LocalTag const&, Buff&) override + { + + } + public: + ForwardingBufferProvider (Listener listener) + : BufferProvider{"BufferProxyProvider"} + , listener_{std::move (listener)} + { } + }; + + ForwardingBufferProvider passThroughProvider_; + public: template> BufferProxyProvider (LIS&& listener) - : listener_{std::forward (listener)} + : passThroughProvider_{std::forward (listener)} { } template BuffHandle lockBuffer (TAR& dataBlock) { + //////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1387 : impossible due to inner contradictions in BufferProvider and OutputSlot UNIMPLEMENTED ("setup type handler and then create a locked BuffHandle"); } diff --git a/tests/core/steam/engine/buffer-proxy-provider-test.cpp b/tests/core/steam/engine/buffer-proxy-provider-test.cpp index 6ecc4b3b9..4a0635bec 100644 --- a/tests/core/steam/engine/buffer-proxy-provider-test.cpp +++ b/tests/core/steam/engine/buffer-proxy-provider-test.cpp @@ -32,11 +32,11 @@ namespace test { /***************************************************************//** - * @test verify the OutputSlot interface and base implementation - * by performing full data exchange cycle. This is a - * kind of "dry run" for documentation purposes, - * both the actual OutputSlot implementation - * as the client using this slot are Mocks. + * @test verify the design of OutputSlot and BufferProvider by + * implementing a delegating BufferProvider to expose + * output data buffers provided from _some implementation._ + * @todo WIP-WIP 12/2024 this turned out to be impossible, + * due to inconsistencies in the default implementation. /////////////////////////////////////////////TICKET #1387 : need to consolidate BufferProvider default implementation */ class OutputProxyProvider_test : public Test { @@ -60,7 +60,7 @@ namespace test { TestFrame dataBlock (frameNr); CHECK ( dataBlock.isPristine()); - BuffHandle handle = proxPro.lockBuffer (dataBlock); + BuffHandle handle = proxPro.lockBuffer (dataBlock); ///////////////////////////////////////////////TICKET #1387 : unable to implement this // Now a »client« can do awful things to the buffer... CHECK (handle.isValid()); diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 6ab98ebf3..10d78b996 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -28459,9 +28459,7 @@ - - - +

aber es bleibt bei diesem Prinzip. @@ -29130,9 +29128,7 @@ - - - +

...weil man stets noch einen Layer darübersetzt? @@ -29691,9 +29687,7 @@ - - - +

|o| cH(line=0) += (14,14) @@ -30878,9 +30872,7 @@ - - - +

nicht alles wird gezeichnet @@ -30962,9 +30954,7 @@ - - - +

manchmal ist die alte Lösung besser @@ -31985,9 +31975,7 @@ - - - +

TiddlyWiki + doc/technical/stage/style/Timeline.txt @@ -32430,9 +32418,7 @@ - - - +

und mehrfach gekapselt. @@ -33328,9 +33314,7 @@ - - - +

tatsächlich ist es dann ein Sub-Interface: der CanvasHook. Und dieser @@ -88166,6 +88150,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + @@ -94715,8 +94703,34 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- - + + + + + +

    +
  • + DataSink liefert ein BuffHandle, hat dann aber eine eigne Methode DataSink::emit() +
    • +
  • + die BuffHandle::emit()-Methode ist nicht richtig integriert... +
    • +
  • + deshalb kann derzeit (12/2024) der Render-Node-Code nicht korrekt mit Output-Buffern umgehen! +
    • +
  • + Grund ist zu enge Verkopplung mit der Default-Implementierung. Siehe #1387 +
    • +
+ + + + + + + + + @@ -94796,8 +94810,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + @@ -95165,7 +95179,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + + @@ -95190,6 +95205,24 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + + + + + + + + + + + + + + + @@ -97845,6 +97878,16 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
+ + + + + + + + + + @@ -97870,7 +97913,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
- + @@ -97878,8 +97921,8 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
brauche also nur noch ein BuffHandle hier

- - + + @@ -97905,8 +97948,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
das würde mir eigentlich gefallen ⟹ packe ich diesen Schritt JETZT?

- - + @@ -98039,8 +98081,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Das könnte ggfs. sogar eine automatische Transformation sein, auf Basis des jetzt definierten Node-Modells; man würde dann eine DAG ⟼ Tree -Transformation machen und dann die jeweilge ausführbare Node über ein Lambda-Binding über eine Prototyp-Node erzeugen.

- - + @@ -98057,11 +98098,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
alles andere würde eine Art Kollaboration oder Protokoll implizieren

- - + - - + + @@ -98105,8 +98145,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
Deshalb möchte ich nun doch einmal aus-implementieren, was denn erforderlich wäre, einen frei-stehenden Buffer-Provider neu zu implementieren, welcher an einen dahinter liegenden OutputSlot delegiert....

- - + @@ -98149,8 +98188,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
...und zwar schon längere Zeit bezüglich der Implementierung  des BufferProvider — das Konzept halte ich für sehr wichtig und auch gelngen. Aber immer wieder, wenn ich dann die Implementierung anschaue, dann springt man irgendwo zwischen dieser Default-Implementierung und dem TrackingHeapBlockProvider hin und her — und der ganze Code „riecht schief“, irgendwie (weiß aber nicht warum) ... Hinzu kommen Probleme (und, wie ich inzwischen weiß, tatsächliche Bugs) in der Typ-Registrierung, also BufferMetadata

- - + @@ -98163,8 +98201,171 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 - - + + + + + + + +

+ ...es sind ja nur vier abstrakte Methoden zu implementieren, die die tatsächlichen Zustandsübergänge markieren +

+ + + + + + + +

+ die Idee war damals wohl, daß die BufferProvider-Basis-Impl einen Sicherheits-Layer  bietet +

+ + + + + +

+ ...will sagen, die Implementierung muß sich bloß noch um ihr eigenes Memory-Management kümmern, aber nicht mehr darum, Typen und Lifecycle-Phasen zu tracken. Das erscheint mir nun durchaus ein plausibler Ansatz zu sein (hätte man bloß besser dokumentieren sollen) +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ und das Ergebnis, das BuffHandle "ist es dann auch" +

+ + + + + + + + + + + + + + + + + +

+ allerdings war das Design nie etwas anderes als vorläufig +

+ + + + + + +

+ ...denn in all honesty, die Prämisse war und ist, daß man auf dieser Basis einen echten BufferProvider implementieren können dürfen sollte +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -100036,6 +100237,10 @@ Date:   Thu Apr 20 18:53:17 2023 +0200
 + + + + @@ -148844,6 +149049,10 @@ unsigned int ThreadIdAsInt = *static_cast<unsigned int*>(static_cast<vo + + + +