benn/lumiera_documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

OutputSlot: integration with buffer management (+documentation)

Browse source 
Within the reworked design of the `OutputSlot` a proxy implementation
of the `BufferProvider` API is used (class `OutputBufferProxy`).

After analysis of the invocation patterns, I concluded that it seems adequate
to attach the special-purpose metadata generated by this integration
to the generic system of thread-local replicated `BufferMetadata` storage.

However, since thread-local instances are effectively static(global),
I was concerned that unit-testing might be impeded by accumulation of
stale metadata in the store linked to the main thread. Thus I created
a special configuration variant to retain the previously used setup
for the sake of unit testing (which applies especially to use of the
`DiagnosticOutputSlot`). Using a `SimpleBufferStateRegistry` for in
that case has the benefit that simply a local instance can be used
in the test and all metadata will be discarded afterwards.

Furthermore the factory syntax for obtaining an `OutputSlot` was improved,
drawing on the recent changes to `lib::ScopedCollection`.

Also I looked through some of the documentation and updated
the UML sequence diagram to reflect `OutputSlot`'s improved internal structure
This commit is contained in:
Fischlurch 2026-05-30 23:49:50 +02:00
parent 9461443e84
commit 216ab525fd
14 changed files with 2521 additions and 154 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
doc/devel/uml/BoUML-diagrams.txt
View file

@ -49,5 +49,4 @@ On occasion, we'll replace them by drawings from our current UML model.
128517: classdiagram 142725 "Time flavours"
133637: classdiagram 143877 "Player Entities"
133637: objectdiagram 144005 "Play Process Structure"
133637: sequencediagram 145157 "output data exchange"
128773: classdiagram 158213 "UIBus"

1672
doc/devel/uml/OutputSlot_sequence.svg Normal file
View file

File diff suppressed because it is too large Load diff
Side by side

After

Width:  |  Height:  |  Size: 82 KiB

BIN
doc/devel/uml/fig145157.png
View file

Binary file not shown.
Side by side

Before

Width:  |  Height:  |  Size: 13 KiB

5
src/vault/mem/buffer-proxy-adaptor.hpp
View file

@ -19,7 +19,7 @@
** between the »Buffer Provider Protocol« and the »Output Slot Protocol«.
** Ultimately, however, it was not used; instead, a similar, specially
** tailored construct was directly integrated.
** @see output-proxy-provider-test.cpp
** @see buffer-proxy-adaptor-test.cpp
** @see output-buffer-proxy.hpp
** @see output-slot.hpp
*/
@ -60,6 +60,7 @@ namespace mem {
* - is there only one resource or is this setup statefull?
* - callback functors for the lifecycle stages related to the client's access
* @todo 3/2026 this is prototyping code and was retained for demonstration purposes.
* @see output-buffer-proxy.hpp (the actual solution derived from this)
*/
template<class CONF>
class BufferProxyAdaptor
@ -87,7 +88,7 @@ namespace mem {
}
BuffAlloc
provideBuffer (HashVal,size_t siz,LocalTag targetMarker, int64_t customArg) override
provideBuffer (HashVal,size_t siz,LocalTag targetMarker, int64_t) override
{
BuffAlloc storageSlot{asBuffer(targetMarker), siz, targetMarker};
CONF::on_lock (storageSlot);

4
src/vault/out/diagnostic-output-slot.cpp
View file

@ -333,7 +333,9 @@ namespace out {
unique_ptr<OutputSlot::Allocation>
DiagnosticOutputSlot::setupTrackingConnections (DiagnosticOutputSlot::OutputTracker& outputTracker)
{
using AllocState = OutputSlot::AllocState<DummyConnection>;
constexpr bool SIMPLE_METADATA_TABLE_FOR_TEST{true};
using AllocState = OutputSlot::AllocState<DummyConnection, SIMPLE_METADATA_TABLE_FOR_TEST>;
using ConStorage = AllocState::ConnectionStorage;
return make_unique<AllocState> (outputTracker.numDataFeeds

50
src/vault/out/output-buffer-proxy.hpp
View file

@ -16,8 +16,15 @@
** This implementation building-block allows to integrate the output buffers
** managed by a specific output mechanism with the generic implementation of
** OutputSlote, so that only a BuffHandle needs to be exposed to the client.
** @see output-proxy-provider-test.cpp
** @see output-buffer-proxy.hpp
** The client uses this setup in accordance to the »Output Slot Protocol«.
** @remark this adaptor is generated automatically when some specific
** output technology is exposed through an OutputSlot; at that
** point, a custom OutputSlot::Connection implementation
** is [instantiated](\ref OutputSlot::allocate), causing
** the setup and wiring of OutputSlot::AllocState<CON>.
** @see buffer-proxy-adaptor-test.cpp (a pathfinder for this design)
** @see output-alloc-state-test.cpp
** @see output-slot-connection.hpp
** @see output-slot.hpp
*/
@ -27,46 +34,44 @@
#include "lib/error.hpp"
#include "lib/nocopy.hpp"
#include "lib/symbol.hpp"
#include "lib/meta/util.hpp"
#include "vault/mem/buffer-provider.hpp"
#include "vault/mem/buffer-provider-setup.hpp"
#include "vault/mem/heap-mem-buffer-store.hpp"
#include "vault/mem/simple-buffer-state-registry.hpp"
#include "vault/mem/local-buffer-stage.hpp"
#include <functional>
#include <utility>
#include <type_traits>
namespace vault{
namespace out {
using std::move;
using lib::Literal;
using lib::HashVal;
using vault::mem::Buff;
using vault::mem::LocalTag;
using vault::mem::BuffAlloc;
using vault::mem::BuffDescr;
using vault::mem::BuffHandle;
using vault::mem::TypeHandler; ///////////////////////////OOO Rly?
using vault::mem::TypeHandler;
using vault::mem::BufferProviderSetup;
/**
* Adapter to expose controlled access to some memory resource
* Adapter to expose controlled access to the \ref OutputSlot::Connection
* through a [»Buffer Type«](\ref BuffDescr) and a BuffHandle as front-end,
* in accordance with the BufferProvider protocol.
*
* This template is an implementation building block and needs to be instantiated
* with a policy or configuration to define the flexible parts of the behaviour
* - what a Buffer Type means
* - is there only one resource or is this setup statefull?
* - callback functors for the lifecycle stages related to the client's access
* @todo 3/2026 this is prototyping code and was retained for demonstration purposes.
* This template is an implementation building block for the OutputSlot and
* creates the crucial link between the DataSink handle exposed to the client
* and the actual implementation of the connection technology. It needs to be
* instantiated with the concrete connection implementation type; this happens
* as part of instantiating OutputSlot::AllocState<CON> — and this is the
* typical way how a concrete connection is packaged into an OutputSlot.
*
* @tparam CON the actual OutputSlot::Connection implementation
* @tparam isTest use a naive self-contained metadata hashtable;
* by default, a threadsafe system of local metadata tables
* is used in conjunction with the EngineBufferMetadata service
*/
template<class CON>
template<class CON, bool isTest=false>
class OutputBufferProxy
: public BufferProviderSetup
{
@ -113,7 +118,10 @@ namespace out {
struct Setup
{
auto buildStage() { return std::make_unique<vault::mem::SimpleBufferStateRegistry>("OutputBufferProxy"); }
using MetadataRegistry = std::conditional_t<isTest, vault::mem::SimpleBufferStateRegistry
, vault::mem::LocalBufferStage>; // ◁──────────┨ by default use the production-grade implementation
auto buildStage() { return std::make_unique<MetadataRegistry>("OutputBufferProxy"); }
auto buildStore() { return std::make_unique<OutputBufferStore>(); }
};

84
src/vault/out/output-slot-connection.hpp
View file

@ -13,13 +13,13 @@
/** @file output-slot-connection.hpp
** Interface for concrete output implementations to talk to the OutputSlot frontend.
** This setup with an OutputSlot concept helps to decouple the render engine implementation
** This setup with an OutputSlot as façade helps to decouple the render engine implementation
** from the details of handling any kind of external output connection. The act of data output
** is reduced to the operations described by the OutputSlot::Connection interface.
**
** # Interplay of parts involved into an actual implementation
**
** Each distinct output capability must be registered through an OutputManager (and this is another
** Each distinct output capability must be registered with an OutputManager (and this is another
** topic beyond the scope of the interaction described here). When a client wants to output data,
** it obtains a suitable OutputSlot through the OutputDirector. This OutputSlot is created and
** initialised properly for this single use by the OutputManager in charge for that kind of
@ -29,26 +29,54 @@
**
** This allocation state is linked at implementation level to some specific implementation of the
** OutputSlot::Connection interface, represented as template parameter \a CON. An instance will be
** created for each distinct data feed (which applies only if the media stream type in question
** comprises several data feeds running in parallel). In many typical cases, only one data feed
** and thus only a single Connection instance is required. The client can then retrieve a DataSink
** handle for each data feed. Notably, each DataSink participates in the ref-count and thus keeps
** the OutputSlot and the Connection(s) alive. Furthermore, [timing constraints](\ref vault::out::Timings)
** must be defined, to instruct the client when to deliver the data for each prospective frame. Obviously,
** created for each distinct data feed — which applies only if the media stream type in question
** comprises several data feeds running in parallel; here a data feed does not necessarily correspond
** to a _channel_, since it is quite common to _interleave_ several channels in a single feed. In many
** typical cases, only one data feed and thus only a single Connection instance is required. The client
** can then retrieve a DataSink handle for each data feed. Notably, each DataSink participates in the
** ref-count and thus keeps the OutputSlot and the Connection(s) alive.
** Furthermore, [timing constraints](\ref vault::out::Timings) must be defined, to instruct the client
** when precisely to deliver the data for each prospective frame (time window of delivery). Obviously,
** details depend on the underlying technology. In some cases, the client might prepare several buffers
** full of data in advance, while for another technology, that, for example, relies on _double buffering_,
** the client gets only a single precisely limited time window immediately prior to each _buffer flip_.
** the client has to meet a single precisely limited time window immediately prior to each _buffer flip_.
**
** The client code interacts with the output data buffer through a BuffHandle as front-end. This access
** scheme is similar to what is used by the generic vault::mem::BufferProvider within the Render Engine.
** To enable this setup, the OutputSlot::AllocState embeds a _proxy BufferProvider_ and uses a preconfigured
** [buffer (type) descriptor](\ref vault::mem::BuffDescr) for each connection, which also includes information
** about the size of the buffer, which is obtained [from the connection](\ref OutputSlot::Connection::getBufferSize)
** about the size of the buffer, as obtained [from the connection](\ref OutputSlot::Connection::getBufferSize).
** To start work on a new frame, the client invokes DataSink, which actually is a functor. This call delegates
** through the proxy BufferProvider — see \ref OutputBufferProxy::provideBuffer() and thus ends up calling
** into Connection::claimBufferFor(frameNr).
**
** ## Threadsafe production-grade implementation
**
** OutputSlot operates as part of the BufferProvider framework within the Render Engine; it must thus
** be capable to handle concurrent access. The construction of a OutputSlot instance happens from a single thread,
** which is typically the session thread (since the output connection is created as part of starting a play process).
** Immediately at construction, an AllocState must be provided, which in turn creates all the connection objects.
** The activation of these connections and the access to output buffers (»lock a buffer) will then be initiated
** from the worker threads. It can be assumed that a single worker processes the job for some output frame, but
** other workers might start processing other output frames concurrently, assuming the underlying connection
** technology allows to produce output in advance this way (which is rather uncommon for real-time output,
** where typically a double-buffering scheme is employed, which implies that at any given time only one
** single output buffer can be exposed; yet for other kinds of output, like e.g. memory mapped file
** output, several frames can be delivered in parallel).
**
** Notably this implies that the connection implementation must be prepared for receiving data concurrently.
** Other than that, the OutputBufferProxy will use a LocalSlice<BufferMetadata>, and thus a thread-local
** metadata table, in concert with the EngineBufferMetadata as central hub. The link to a connection object
** for a single channel is represented as a [»buffer type«](\ref BuffDescr). When a worker »locks« some
** frame, the BufferProvider implementation will access the thread-local metadata store to track the
** state transitions; on first usage it will have to sync-down the type descriptor from the central hub.
**
** For the purpose of unit testing, a simple self-contained metadata table can be used instead, which has the
** advantage that all state is discarded when deleting the OutputSlot object. In fact, most unit tests rely on
** the \ref DiagnosticOutputSlot, which sets the `isTest` template parameter internally to use this variant.
**
** @see OutputSlotProtocol_test
** @see OutputAllocState_test
*/
@ -104,6 +132,9 @@ namespace out {
* `publish()` is invoked too late, but must keep the buffer in locked / exclusive
* state, since the client might still be writing data, even after the deadline.
* @note the meaning of FrameID is implementation defined.
* @warning the Connection implementation must be threadsafe; while there will be never
* any contention regarding a single frame number, consecutive frames can and will
* be delivered by different threads, concurrently.
*/
class OutputSlot::Connection
: util::NonCopyable
@ -134,14 +165,15 @@ namespace out {
* Theses smart-handles are ref counting and thus the individual
* Connection object is kept alive as long as at least one DataSink
* handle is retained.
* @tparam isTest use a simple BufferMetadata table in OutputBufferProxy.
*/
template<class CON>
template<class CON, bool isTest=false>
class OutputSlot::AllocState
: public OutputSlot::Allocation
{
using Connections = lib::ScopedCollection<CON>;
using OpenedSinks = OutputSlot::OpenedSinks;
using BufferProxy = OutputBufferProxy<Connection>;
using BufferProxy = OutputBufferProxy<Connection, isTest>;
Connections connections_;
BufferProxy bufferProxy_;
@ -215,5 +247,33 @@ namespace out {
/* ===== OutputSlot factory functions ===== */
/**
* @remark this is the generic builder variant, using a _populator functor_
* that is passed directly to the constructor of lib::ScopedConnection
*/
template<class CON, class FUN>
OutputSlot
OutputSlot::allocate (size_t cnt, FUN&& populator)
{
return OutputSlot{std::make_unique<AllocState<CON>> (cnt, std::forward<FUN>(populator))};
}
/**
* @remark in moste cases this variant is preferable,
* since it creates all connection objects from the same set of constructor arguments
* @note args will be copied into a _populator functor_ that is then applied for each connection to create
*/
template<class CON, typename...ARGS>
requires std::is_constructible_v<CON, ARGS...>
OutputSlot
OutputSlot::allocate (size_t cnt, ARGS&&... args)
{
using Connections = lib::ScopedCollection<CON>;
return OutputSlot{std::make_unique<AllocState<CON>> (cnt, Connections::fill(std::forward<ARGS>(args)...) )};
}
}} // namespace vault::out
#endif /*VAULT_OUT_OUTPUT_SLOT_CONNECTION_H*/

15
src/vault/out/output-slot.hpp
View file

@ -14,7 +14,7 @@
/** @file output-slot.hpp
** An (abstract) capability to send media data to an external output.
** OutputSlot is the central metaphor for the organisation of actual (system level) outputs;
** using this concept allows to separate and abstract the data calculation and the organisation
** using this pattern allows to separate and abstract the data calculation and the organisation
** of playback and rendering from the specifics of the actual output sink. Actual output
** possibilities can be added and removed dynamically from various components (vault, stage),
** all using the same resolution and mapping mechanisms
@ -185,7 +185,7 @@ namespace out {
* @internal Implementation subclass:
* manage active connections through this OutputSlot
*/
template<class CON>
template<class CON, bool isTest=false>
class AllocState;
@ -209,13 +209,14 @@ namespace out {
* @note usually there is no need to subclass OutputSlot or AllocState,
* rather this factory should be used to establish an activated
* OutputSlot configured to use a specific OutputSlot::Connection.
* @see output-slot-connection.hpp
*/
template<class CON, typename...ARGS>
requires std::is_constructible_v<CON, ARGS...>
static OutputSlot allocate (size_t cnt, ARGS&&... args);
template<class CON, class FUN>
static OutputSlot
allocate (size_t cnt, FUN&& populator)
{
return OutputSlot{std::make_unique<AllocState<CON>> (cnt, std::forward<FUN>(populator))};
}
static OutputSlot allocate (size_t cnt, FUN&& populator);
};

3
tests/vault/mem/buffer-proxy-adaptor-test.cpp
View file

@ -41,9 +41,10 @@ namespace test {
* rigged such that a pre-existing given buffer (address) can be
* passed through and exposed as BuffHandle.
* @remark while this looks like a rather convoluted implementation setup,
* this feature is crucial to make the »Output Slot Protocol«
* this feature was crucial to make the »Output Slot Protocol«
* mesh up well ([1415]) with the »Buffer Provider Protocol«,
* used internally within the Render Engine
* @see output-buffer-proxy.hpp (the implementation actually used)
* [1415]: https://issues.lumiera.org/ticket/1415]
*/
class BufferProxyAdaptor_test : public Test

1
tests/vault/mem/local-mem-pool-test.cpp
View file

@ -22,7 +22,6 @@
#include "lib/iter-explorer.hpp"
#include "lib/iter-stack.hpp"
#include "lib/format-util.hpp"
#include "test/diagnostic-output.hpp"////////////TODO
#include <concepts>

23
tests/vault/out/output-alloc-state-test.cpp
View file

@ -100,17 +100,18 @@ namespace vault::out::test {
~MockConnection() { log.call ("MockConnection", "destroy"); }
};
struct FakeSlot
: OutputSlot
{
static constexpr uint NUM_CONNECTIONS = 1;
static constexpr bool SINGLE_THREADED_TEST = true;
using Connections = lib::ScopedCollection<MockConnection>;
using MockConnectState = OutputSlot::AllocState<MockConnection, SINGLE_THREADED_TEST>;
inline OutputSlot
makeFakeSlot()
{
const uint NUM_CONNECTIONS = 1;
return OutputSlot::allocate<MockConnection> (NUM_CONNECTIONS
,[](auto& storage)
{
storage.template create<MockConnection>();
});
}
FakeSlot()
: OutputSlot{std::make_unique<MockConnectState> (NUM_CONNECTIONS, Connections::fill())}
{ }
};
}//(End) test fixture
@ -139,7 +140,7 @@ namespace vault::out::test {
const FrameCnt FRA_NO = 55;
{
log.event("create FakeSlot");
auto slot = makeFakeSlot();
FakeSlot slot;
log.event("retrieve DataSink");
auto sinks = slot.getOpenedSinks();

188
uml/Lumiera.xmi
View file

@ -3,7 +3,6 @@
<xmi:Documentation exporter="umbrello uml modeller 25.04.2 (Applications 25.04.2) http://umbrello.kde.org" exporterVersion="2.0.4"/>
<uml:Model xmi:id="m1" name="UML Model">
<packagedElement xmi:type="uml:Stereotype" xmi:id="folder" name="folder"/>
<packagedElement xmi:type="uml:Stereotype" xmi:id="datatype" name="datatype"/>
<packagedElement xmi:type="uml:Stereotype" xmi:id="constructor" name="constructor"/>
<packagedElement xmi:type="uml:Stereotype" xmi:id="friend" name="friend"/>
<packagedElement xmi:type="uml:Stereotype" xmi:id="virtual" name="virtual"/>
@ -13,30 +12,35 @@
<packagedElement xmi:type="uml:Stereotype" xmi:id="smart_handle" name="smart_handle"/>
<packagedElement xmi:type="uml:Model" xmi:id="Logical View" name="Logical View" stereotype="folder">
<uml:Package xmi:id="Datatypes" name="Datatypes" stereotype="folder">
<packagedElement xmi:type="uml:DataType" xmi:id="mhSdaAG81L4V" name="int" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="15L0hJXhwcFR" name="char" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="c4Twqn0aUQB4" name="bool" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="aPBblD5kGQlv" name="float" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="hGddsq3TsUPg" name="double" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="mhSdaAG81L4V" name="int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="15L0hJXhwcFR" name="char" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="c4Twqn0aUQB4" name="bool" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="aPBblD5kGQlv" name="float" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="hGddsq3TsUPg" name="double" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="HOEjoPmPovyX" name="short" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="83IMS1F7HsjA" name="long" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="gkbWE0CWOQFD" name="unsigned int" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="gkbWE0CWOQFD" name="unsigned int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="n1aawY72aPM0" name="unsigned short" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="Qc5iSoq7YRdn" name="unsigned long" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="RoHoEUz0UZaO" name="string" stereotype="datatype"/>
<packagedElement xmi:type="uml:DataType" xmi:id="RoHoEUz0UZaO" name="string" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="pFknC1jVXUTk" name="Session*" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uMMCCegdWRMed" name="unsigned char" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uNC1udGnuzN2S" name="signed char" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="ub2aLimnOvCc8" name="signed int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uQjH8LmECcyqd" name="short int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uI4uVfXWHwlj8" name="unsigned short int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="ufJzUkPpx5QnH" name="signed short int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uNqycOxR6x9BP" name="long int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uTDfsr4Knx3AZ" name="signed long int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uIVzscMhthEou" name="unsigned long int" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uWIJRjMnWEHh8" name="long double" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="unGP2JF0ACOa5" name="wchar_t" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uMMCCegdWRMed" name="unsigned char" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uNC1udGnuzN2S" name="signed char" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="ub2aLimnOvCc8" name="signed int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uQjH8LmECcyqd" name="short int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uI4uVfXWHwlj8" name="unsigned short int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="ufJzUkPpx5QnH" name="signed short int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uNqycOxR6x9BP" name="long int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uTDfsr4Knx3AZ" name="signed long int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uIVzscMhthEou" name="unsigned long int" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uWIJRjMnWEHh8" name="long double" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="unGP2JF0ACOa5" name="wchar_t" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="u7wTiAdmiAByJ" name="undef" stereotype="dataType" isActive="false"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uVxgjODi2MBCq" name="String" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uJPH4z4moUrAV" name="Boolean" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uRq5pJ7Ak7Ey7" name="UnlimitedNatural" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uvkDnW2TlWh7K" name="Integer" stereotype="dataType"/>
<packagedElement xmi:type="uml:DataType" xmi:id="uT7ZNi38azbf5" name="Real" stereotype="dataType"/>
</uml:Package>
<uml:Package xmi:id="dzlPCiVfMhDw" name="GUI" stereotype="folder">
<uml:Package xmi:id="AP2Jw6O9SyPl" name="Backbone" stereotype="folder">
@ -333,6 +337,7 @@
</ownedOperation>
<ownedOperation xmi:type="uml:Operation" xmi:id="uD216HGDrEbGk" name="getTimings"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="uQEgCpAllbbm3" name="getOpenedSinks"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="uHC0fucKtP5ko" name="allocate" ownerScope="classifier"/>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="uUqbRaeXT7fNx" name="OutputManager" visibility="implementation">
<ownedOperation xmi:type="uml:Operation" xmi:id="umG1eERfGXLWz" name="openOutput">
@ -359,7 +364,6 @@
<ownedOperation xmi:type="uml:Operation" xmi:id="u0R3WQdQJmmUp" name="shutDown" isVirtual="true"/>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="u5kuKJrlM1zly" name="AllocState">
<ownedParameter xmi:type="uml:ClassifierTemplateParameter" xmi:id="uCyAVPudYbQe3" name="CON"/>
<generalization xmi:type="uml:Generalization" xmi:id="uNwZZVhJYJiUz" general="u7wTiAdmiAByJ"/>
<generalization xmi:type="uml:Generalization" xmi:id="uoSTMEoei8G00" general="u7wTiAdmiAByJ"/>
<generalization xmi:type="uml:Generalization" xmi:id="ued1fAoHx5qeL" general="ues4Riovaqpbr"/>
@ -374,6 +378,10 @@
<ownedOperation xmi:type="uml:Operation" xmi:id="upDZEVWFoEgrj" name="release"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="uXc0jayqgvLcp" name="getTimings" isVirtual="true"/>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="u99leNLtBz2zk" name="BufferProxy">
<ownedOperation xmi:type="uml:Operation" xmi:id="uIqGRQaOClVH1" name="mark_emitted"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="u0RVaQUf6Iogp" name="detachBuffer"/>
</packagedElement>
<xmi:Extension extender="umbrello">
<diagrams>
<diagram xmi.id="uCRIwrHyUI7XP" name="OutputSlot_components" type="1" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#990000" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="0" showops="1" showopsig="0" showpackage="0" showpubliconly="0" showscope="0" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="1" snapx="5" snapy="5" zoom="123" canvasheight="800" canvaswidth="1200" isopen="1">
@ -386,10 +394,10 @@
<classwidget xmi.id="ugZ3tw8emNmCk" localid="uZxZJpq9678xS" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="595" y="580" width="140" height="50" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<notewidget xmi.id="uxrjVPencXlRU" localid="uiPwuozqE0e72" textcolor="#000000" linecolor="#0055ff" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#aaffff" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="85" y="130" width="125" height="45" isinstance="0" showstereotype="2" text="Client&#10;front-end" noteType="0"/>
<classwidget xmi.id="uUqbRaeXT7fNx" localid="uZQj2N5Q7D43J" textcolor="#000000" linecolor="#00557f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#9bffd0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="210" y="260" width="145" height="95" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uMC7JhfSjNmhE" localid="uB0CKUWqZQqbu" textcolor="#000000" linecolor="#00557f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#9bffd0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="500" y="455" width="120" height="85" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="ubYkCE7vQXUGD" localid="uioySnLsOFP1b" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="95" y="490" width="80" height="50" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uMC7JhfSjNmhE" localid="uB0CKUWqZQqbu" textcolor="#000000" linecolor="#00557f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#9bffd0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="500" y="455" width="125" height="85" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="ubYkCE7vQXUGD" localid="uioySnLsOFP1b" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="95" y="490" width="80" height="65" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uf10mauSZTRhO" localid="uTLPu4PPbxsHQ" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="500" y="165" width="120" height="95" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uSdMfvm7i7gGI" localid="uk2QoQY3kWuYL" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="225" y="80" width="120" height="70" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uSdMfvm7i7gGI" localid="uk2QoQY3kWuYL" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="225" y="80" width="120" height="85" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<classwidget xmi.id="uJTVhWsuR8ex1" localid="uTGTNRUFUOYII" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="85" y="365" width="100" height="45" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
<boxwidget xmi.id="uhFswWzqhhnkR" localid="uK8vrS3Ybe9uS" textcolor="#000000" linecolor="#8284e2" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="195" y="45" width="270" height="245" isinstance="0" showstereotype="2"/>
<classwidget xmi.id="u5kuKJrlM1zly" localid="u1W5rrajsHSPA" textcolor="#000000" linecolor="#990000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="305" y="345" width="180" height="110" isinstance="0" showstereotype="2" showoperations="1" showpubliconly="0" showopsigs="603" showpackage="0" showscope="0" showattributes="1" showattsigs="603"/>
@ -504,6 +512,95 @@
</assocwidget>
</associations>
</diagram>
<diagram xmi.id="u7TfqV7QmzKve" name="OutputSlot_sequence" type="3" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#00004f" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="0" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="1" snapx="5" snapy="5" zoom="100" canvasheight="800" canvaswidth="1100" isopen="1" autoincrementsequence="0">
<widgets>
<notewidget xmi.id="ufsQByR7djzq2" localid="uaL7wU9D8N6r0" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#e7ffb4" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="460" y="75" width="290" height="35" isinstance="0" showstereotype="2" text="Output Slot" noteType="0"/>
<notewidget xmi.id="uFkBVzKXkrYGS" localid="u3JMf2HEZ452d" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#e7ffb4" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="910" y="210" width="120" height="45" isinstance="0" showstereotype="2" text="Output&#10;implementation" noteType="0"/>
<combinedFragmentwidget xmi.id="uglXmsiHzsb4g" localid="uMt4y2zno2TE7" textcolor="#000000" linecolor="#a087c0" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="-55" y="265" width="365" height="395" isinstance="0" showstereotype="2" combinedFragmentname="N" documentation="" CombinedFragmenttype="3"/>
<notewidget xmi.id="udzXcBdfKXM23" localid="uXL80EcZWUfTF" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#e7ffb4" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="-20" y="40" width="120" height="30" isinstance="0" showstereotype="2" text="Data producer" noteType="0"/>
<objectwidget xmi.id="u99leNLtBz2zk" localid="u4InFUkwChyHR" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="665" y="155" width="85" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="1"/>
<objectwidget xmi.id="ubYkCE7vQXUGD" localid="uBQBOWPp6m8U5" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="125" y="305" width="80" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="1"/>
<objectwidget xmi.id="uf10mauSZTRhO" localid="uI1z82QXwYiQQ" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="855" y="175" width="85" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="0"/>
<objectwidget xmi.id="uSiylHvSuVNrJ" localid="u4T9CLqTe5m4g" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="10" y="80" width="55" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="0"/>
<objectwidget xmi.id="uUqbRaeXT7fNx" localid="uRILJYeVkBev5" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="265" y="80" width="105" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="0"/>
<objectwidget xmi.id="uJTVhWsuR8ex1" localid="uHKTgvdSF1PM4" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="190" y="215" width="80" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="1"/>
<objectwidget xmi.id="uSdMfvm7i7gGI" localid="uk192oAycB8ab" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="460" y="125" width="80" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="1"/>
<objectwidget xmi.id="u5kuKJrlM1zly" localid="uKBYpT8cvN97E" textcolor="#000000" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="555" y="140" width="75" height="25" isinstance="0" showstereotype="2" drawasactor="0" multipleinstance="0" decon="1"/>
</widgets>
<messages>
<messagewidget xmi.id="u2QDZG7YnsdAP" localid="uD0WrcY04MWOg" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="754.296" width="471" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uk192oAycB8ab" operation="destroy" sequencemessagetype="1005" textid="uKiWkhdSTlxmQ">
<floatingtext xmi.id="uKiWkhdSTlxmQ" localid="upz9BLvdk6ehP" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="45" y="735" width="55" height="20" isinstance="0" showstereotype="2" text="destroy" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="ugDNaJenObTKH" localid="uTW0FRGYTeNmH" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="500" y="755" width="215" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uk192oAycB8ab" widgetbid="u4InFUkwChyHR" operation="destroy" sequencemessagetype="1005" textid="utPN1uk50ZGE1">
<floatingtext xmi.id="utPN1uk50ZGE1" localid="u8BkbIdFK9UFR" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="535" y="735" width="55" height="20" isinstance="0" showstereotype="2" text="destroy" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uiZrCsGaeI0iR" localid="uJyFUhQ1rXdAK" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="738.69" width="201" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uHKTgvdSF1PM4" operation="destroy" sequencemessagetype="1005" textid="uyIQjopKqdj5a">
<floatingtext xmi.id="uyIQjopKqdj5a" localid="un02TmQgqW3z1" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="45" y="720" width="55" height="20" isinstance="0" showstereotype="2" text="destroy" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="u6B7N4JR4p596" localid="uPOYrPZwX9IEM" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="35" y="400.676" width="50" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="u4T9CLqTe5m4g" operation="generate data" sequencemessagetype="1000" textid="uyLApX0Pnsfz3">
<floatingtext xmi.id="uyLApX0Pnsfz3" localid="uYDDRJCM0LLTp" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="40" y="380" width="95" height="20" isinstance="0" showstereotype="2" text="generate data" pretext="" posttext="" role="705"/>
</messagewidget>
<messagewidget xmi.id="u0R3WQdQJmmUp" localid="u2De9J7lGkXUF" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="592" y="790" width="313" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="uKBYpT8cvN97E" widgetbid="uI1z82QXwYiQQ" operation="u0R3WQdQJmmUp" sequencemessagetype="1000" textid="uCAm53tKFxn2X">
<floatingtext xmi.id="uCAm53tKFxn2X" localid="uwIP4BCuVv4nY" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="805" y="770" width="80" height="20" isinstance="0" showstereotype="2" text="shutDown()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="um1TPC4nISCjR" localid="u7ZaRxdxwxFyJ" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="707" y="500" width="198" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4InFUkwChyHR" widgetbid="uI1z82QXwYiQQ" operation="um1TPC4nISCjR" sequencemessagetype="1000" textid="uuULDPv6ZlDgS">
<floatingtext xmi.id="uuULDPv6ZlDgS" localid="u9R7Et5IwyStb" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="815" y="480" width="65" height="20" isinstance="0" showstereotype="2" text="publish()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uIqGRQaOClVH1" localid="uFxn09F4Hv2Gh" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="166" y="500.027" width="540" height="19" isinstance="0" showstereotype="2" seqnum="" widgetaid="uBQBOWPp6m8U5" widgetbid="u4InFUkwChyHR" operation="uIqGRQaOClVH1" sequencemessagetype="1001" textid="uB5pXkkP8Rneu">
<floatingtext xmi.id="uB5pXkkP8Rneu" localid="uFc4u3DC2V0l8" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="600" y="480" width="105" height="20" isinstance="0" showstereotype="2" text="mark_emitted()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="u0RVaQUf6Iogp" localid="u5kaWGWy2RqwU" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="166" y="574.678" width="540" height="19" isinstance="0" showstereotype="2" seqnum="" widgetaid="uBQBOWPp6m8U5" widgetbid="u4InFUkwChyHR" operation="u0RVaQUf6Iogp" sequencemessagetype="1001" textid="ufuR6PhMp4ol4">
<floatingtext xmi.id="ufuR6PhMp4ol4" localid="uEZYjtQYZBKrm" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="605" y="555" width="95" height="20" isinstance="0" showstereotype="2" text="detachBuffer()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="u0MVfw1jTGLqj" localid="uKCsCTQZ1e5P4" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="38" y="500.027" width="126" height="19" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uBQBOWPp6m8U5" operation="u0MVfw1jTGLqj" sequencemessagetype="1001" textid="uMdo3o3KHLZpe">
<floatingtext xmi.id="uMdo3o3KHLZpe" localid="u4irIWOGikWXY" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="45" y="480" width="45" height="20" isinstance="0" showstereotype="2" text="emit()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uQdo4d1WDCUMA" localid="uDg7rXcnqyzGX" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="707" y="574.764" width="198" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4InFUkwChyHR" widgetbid="uI1z82QXwYiQQ" operation="uQdo4d1WDCUMA" sequencemessagetype="1000" textid="u0uusKove4EJl">
<floatingtext xmi.id="u0uusKove4EJl" localid="ur56fKXu8Y8dg" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="815" y="555" width="65" height="20" isinstance="0" showstereotype="2" text="release()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uBzHrBd7C8T8g" localid="u8wejNJKKIFW0" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="38" y="573.607" width="126" height="19" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uBQBOWPp6m8U5" operation="uBzHrBd7C8T8g" sequencemessagetype="1001" textid="uLNo9WyZIEMI3">
<floatingtext xmi.id="uLNo9WyZIEMI3" localid="uFfzmjWOCuFrk" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="45" y="555" width="65" height="20" isinstance="0" showstereotype="2" text="release()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uK9lT638Carkb" localid="uc8xQC7ogP4cZ" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="500" y="775" width="100" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uk192oAycB8ab" widgetbid="uKBYpT8cvN97E" operation="destroy" sequencemessagetype="1005" textid="uEHVppJWJ19Yt">
<floatingtext xmi.id="uEHVppJWJ19Yt" localid="ufCGjjAhRES90" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="505" y="755" width="55" height="20" isinstance="0" showstereotype="2" text="destroy" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uOIAYPgU3bE4z" localid="uYYQysLFXNEns" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="599.29" width="136" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uBQBOWPp6m8U5" operation="done" sequencemessagetype="1005" textid="ujqOS2afSg4t3">
<floatingtext xmi.id="ujqOS2afSg4t3" localid="ugsts4aajMO59" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="50" y="580" width="40" height="20" isinstance="0" showstereotype="2" text="done" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="ulXYOC6H67SU5" localid="uvAS5yIHsqRCy" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="707" y="304.4" width="198" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4InFUkwChyHR" widgetbid="uI1z82QXwYiQQ" operation="ulXYOC6H67SU5" sequencemessagetype="1000" textid="uBVM7gPYc2Lr2">
<floatingtext xmi.id="uBVM7gPYc2Lr2" localid="uFaGzVs2FB2mK" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="785" y="285" width="95" height="20" isinstance="0" showstereotype="2" text="claimBufferFor()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uD1J8J1aw2s1k" localid="uLzxXSfIovckW" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="230" y="284.006" width="485" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="uHKTgvdSF1PM4" widgetbid="u4InFUkwChyHR" operation="lockBuffer" sequencemessagetype="1000" textid="uN5NkaLKZ37GY">
<floatingtext xmi.id="uN5NkaLKZ37GY" localid="uhr3QXiMnqco1" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="245" y="265" width="65" height="20" isinstance="0" showstereotype="2" text="lockBuffer" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uyKUD1PNCzz8A" localid="upogMLNX6U1Io" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="166" y="363.958" width="730" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uBQBOWPp6m8U5" widgetbid="uI1z82QXwYiQQ" operation="access buffer" sequencemessagetype="1001" textid="ufycbWb6rS7Ii">
<floatingtext xmi.id="ufycbWb6rS7Ii" localid="uf5cxqoJxI2OW" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="800" y="345" width="90" height="20" isinstance="0" showstereotype="2" text="access buffer" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="usSq4lsXlwcI9" localid="uJcxZi6fcKVLj" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="283.929" width="201" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uHKTgvdSF1PM4" operation="frame(#)" sequencemessagetype="1000" textid="u82B82FXKXCV0">
<floatingtext xmi.id="u82B82FXKXCV0" localid="uPP0gWP6VEze6" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="170" y="265" width="50" height="20" isinstance="0" showstereotype="2" text="frame()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uTdaJt179nU9j" localid="uVX1VTV4tC2Ct" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="360.282" width="136" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uBQBOWPp6m8U5" operation="uTdaJt179nU9j" sequencemessagetype="1000" textid="uYl0AClrPK58O">
<floatingtext xmi.id="uYl0AClrPK58O" localid="uBfa4nNz7g0QH" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="50" y="340" width="70" height="20" isinstance="0" showstereotype="2" text="accessAs()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uwT9X4vcgNctE" localid="uuHHdyVnGprio" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="593" y="167.5" width="71" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uKBYpT8cvN97E" widgetbid="u4InFUkwChyHR" operation="" sequencemessagetype="1002"/>
<messagewidget xmi.id="uYJYL50OqGMJo" localid="uioZy9ze1HHSs" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="206" y="317.5" width="500" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4InFUkwChyHR" widgetbid="uBQBOWPp6m8U5" operation="" sequencemessagetype="1002"/>
<messagewidget xmi.id="uibGYT3ZY64jv" localid="uum1Uy3phUZTb" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="593" y="187.5" width="261" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uKBYpT8cvN97E" widgetbid="uI1z82QXwYiQQ" operation="" sequencemessagetype="1002"/>
<messagewidget xmi.id="uQPT7l2fa7h4S" localid="udwIQwhZKLX9Q" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="501" y="152.5" width="53" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uk192oAycB8ab" widgetbid="uKBYpT8cvN97E" operation="" sequencemessagetype="1002"/>
<messagewidget xmi.id="uQEgCpAllbbm3" localid="ueb3gIRosUSgR" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="0" x="37" y="197.114" width="471" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uk192oAycB8ab" operation="uQEgCpAllbbm3" sequencemessagetype="1000" textid="uouXfvUIC7C5e">
<floatingtext xmi.id="uouXfvUIC7C5e" localid="uF09NX7XgUsWx" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="365" y="177" width="105" height="20" isinstance="0" showstereotype="2" text="getOpenedSinks()" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uPvt42BVxgFA5" localid="uXraxJ8f4vnqO" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="37" y="127.482" width="288" height="20" isinstance="0" showstereotype="2" seqnum="" widgetaid="u4T9CLqTe5m4g" widgetbid="uRILJYeVkBev5" operation="getOutput" sequencemessagetype="1000" textid="uu52WQHSSkUe9">
<floatingtext xmi.id="uu52WQHSSkUe9" localid="uTF8Kf24vAQKc" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="195" y="107" width="65" height="20" isinstance="0" showstereotype="2" text="getOutput" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uFyJ5DQrHXNdA" localid="uUCCc4ydAkR7N" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="271" y="227.5" width="228" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uk192oAycB8ab" widgetbid="uHKTgvdSF1PM4" operation="new" sequencemessagetype="1002" textid="uYkCcaK4pqlYE">
<floatingtext xmi.id="uYkCcaK4pqlYE" localid="uQBOJzYisiBeR" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="275" y="210" width="30" height="20" isinstance="0" showstereotype="2" text="new" pretext="" posttext="" role="704"/>
</messagewidget>
<messagewidget xmi.id="uHC0fucKtP5ko" localid="uVtbAfEMx1B8x" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="318" y="137.5" width="141" height="8" isinstance="0" showstereotype="2" seqnum="" widgetaid="uRILJYeVkBev5" widgetbid="uk192oAycB8ab" operation="uHC0fucKtP5ko" sequencemessagetype="1002" textid="uQjK1PCp97fLT">
<floatingtext xmi.id="uQjK1PCp97fLT" localid="uCmJUTDzIZS8d" textcolor="none" linecolor="#00004f" linewidth="0" usefillcolor="1" usesdiagramfillcolor="1" usesdiagramusefillcolor="1" fillcolor="none" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" autoresize="1" x="330" y="120" width="60" height="20" isinstance="0" showstereotype="2" text="allocate()" pretext="" posttext="" role="704"/>
</messagewidget>
</messages>
<associations/>
</diagram>
</diagrams>
</xmi:Extension>
</uml:Package>
@ -517,6 +614,7 @@
<packagedElement xmi:type="uml:Class" xmi:id="ubYkCE7vQXUGD" name="BuffHandle">
<ownedOperation xmi:type="uml:Operation" xmi:id="u0MVfw1jTGLqj" name="emit"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="uBzHrBd7C8T8g" name="release"/>
<ownedOperation xmi:type="uml:Operation" xmi:id="uTdaJt179nU9j" name="accessAs"/>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="u5JicU0GNjitG" name="BufferProxyAdaptor">
<ownedOperation xmi:type="uml:Operation" xmi:id="u46jLezHhgh92" name="getDescriptor"/>
@ -691,9 +789,10 @@
<ownedEnd xmi:type="uml:AssociationEnd" xmi:id="udAyJLtoaGSuh" name="" type="u5JicU0GNjitG" aggregation="aggregate" isNavigable="true" changeability="changeable"/>
<ownedEnd xmi:type="uml:AssociationEnd" xmi:id="uadFmUGzHMRee" name="" type="ubYkCE7vQXUGD" aggregation="none" isNavigable="true" changeability="changeable"/>
</packagedElement>
<packagedElement xmi:type="uml:Class" xmi:id="uSiylHvSuVNrJ" name="Client"/>
<xmi:Extension extender="umbrello">
<diagrams>
<diagram xmi.id="IIIwYfFi2Hzy" name="clip_display" type="1" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#990000" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="1" snapx="10" snapy="10" zoom="100" canvasheight="410" canvaswidth="560" isopen="1">
<diagram xmi.id="IIIwYfFi2Hzy" name="clip_display" type="1" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#00004f" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="1" snapx="10" snapy="10" zoom="100" canvasheight="410" canvaswidth="560" isopen="1">
<widgets>
<classwidget xmi.id="YML3K4y9h5tE" localid="h5idAOxedsSi" textcolor="#000000" linecolor="#3e0f00" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,0,50,0,0,0,0,0" autoresize="1" x="200" y="260" width="100" height="30" isinstance="0" showstereotype="1" showoperations="1" showpubliconly="1" showopsigs="601" showpackage="0" showscope="1" showattributes="1" showattsigs="601"/>
<classwidget xmi.id="TxRGe5zBPLEk" localid="NAt4DnJss1W0" textcolor="#000000" linecolor="#3e0f00" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,0,50,0,0,0,0,0" autoresize="1" x="340" y="310" width="90" height="30" isinstance="0" showstereotype="1" showoperations="1" showpubliconly="1" showopsigs="601" showpackage="0" showscope="1" showattributes="1" showattsigs="601"/>
@ -782,7 +881,7 @@
</assocwidget>
</associations>
</diagram>
<diagram xmi.id="C5tERlQ98tP3" name="CommandAccess" type="1" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#990000" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="0" snapx="5" snapy="5" zoom="110" canvasheight="379.364" canvaswidth="617.152" isopen="0">
<diagram xmi.id="C5tERlQ98tP3" name="CommandAccess" type="1" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#00004f" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="1" snapgrid="1" snapcsgrid="0" snapx="5" snapy="5" zoom="110" canvasheight="379.364" canvaswidth="617.152" isopen="0">
<widgets>
<floatingtext xmi.id="wpmINPF0EHuA" localid="U5feokOwe3sT" textcolor="#000000" linecolor="#3e0f00" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,5,50,0,0,0,0,0,Oblique" autoresize="1" x="255" y="355" width="30" height="18" isinstance="0" showstereotype="1" text="GUI" pretext="" posttext="" role="700"/>
<floatingtext xmi.id="kZZOaRpWFbmc" localid="iL564mOWs2Ae" textcolor="#000000" linecolor="#3e0f00" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,5,50,0,0,0,0,0,Oblique" autoresize="1" x="395" y="345" width="84" height="18" isinstance="0" showstereotype="1" text="Steam-Layer" pretext="" posttext="" role="700"/>
@ -948,7 +1047,7 @@
</packagedElement>
<xmi:Extension extender="umbrello">
<diagrams>
<diagram xmi.id="Q1qEMiNK0mHL" name="CommandUsage" type="2" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#990000" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="0" snapgrid="0" snapcsgrid="0" snapx="25" snapy="25" zoom="100" canvasheight="488.96" canvaswidth="468" isopen="1">
<diagram xmi.id="Q1qEMiNK0mHL" name="CommandUsage" type="2" documentation="" backgroundcolor="#f5e7c3" usebackgroundcolor="0" fillcolor="#ffffc0" font="DejaVu Sans Condensed,9,-1,5,50,0,0,0,0,0,Book" griddotcolor="#e5d8b6" linecolor="#00004f" linewidth="0" textcolor="#000000" usefillcolor="1" showattribassocs="1" showatts="1" showattsig="1" showops="1" showopsig="1" showpackage="1" showpubliconly="0" showscope="1" showstereotype="2" localid="-1" showgrid="0" snapgrid="0" snapcsgrid="0" snapx="25" snapy="25" zoom="100" canvasheight="488.96" canvaswidth="468" isopen="1">
<widgets>
<boxwidget xmi.id="wMW5l9TCAHOW" localid="bJB4Uoi9qGKs" textcolor="#000000" linecolor="#000000" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,0,50,0,0,0,0,0" autoresize="1" x="200" y="126" width="277" height="377" isinstance="0" showstereotype="1"/>
<actorwidget xmi.id="zlqyX5J6PSBr" localid="Et047Kv3eR6O" textcolor="#000000" linecolor="#3e0f00" linewidth="0" usefillcolor="1" usesdiagramfillcolor="0" usesdiagramusefillcolor="0" fillcolor="#ffffc0" font="DejaVu Sans,8,-1,0,50,0,0,0,0,0" autoresize="1" x="383" y="50" width="85" height="58.6905" isinstance="0" showstereotype="1"/>
@ -1010,32 +1109,20 @@
<packagedElement xmi:type="uml:Model" xmi:id="Entity Relationship Model" name="Entity Relationship Model" stereotype="folder"/>
</uml:Model>
<xmi:Extension extender="umbrello">
<docsettings viewid="uCRIwrHyUI7XP" documentation="" uniqueid="un9oDNMzFHs17"/>
<docsettings viewid="u7TfqV7QmzKve" documentation="" uniqueid="uXL80EcZWUfTF"/>
<listview>
<listitem id="Views" type="800" open="1">
<listitem id="Component View" type="821" open="1"/>
<listitem id="Deployment View" type="827" open="1"/>
<listitem id="Entity Relationship Model" type="836" open="1"/>
<listitem id="Logical View" type="801" open="1">
<listitem id="uSiylHvSuVNrJ" type="813" open="1"/>
<listitem id="Datatypes" type="830" open="0">
<listitem id="c4Twqn0aUQB4" type="829" open="1"/>
<listitem id="15L0hJXhwcFR" type="829" open="1"/>
<listitem id="hGddsq3TsUPg" type="829" open="1"/>
<listitem id="aPBblD5kGQlv" type="829" open="1"/>
<listitem id="mhSdaAG81L4V" type="829" open="1"/>
<listitem id="uWIJRjMnWEHh8" type="829" open="0"/>
<listitem id="uNqycOxR6x9BP" type="829" open="0"/>
<listitem id="uQjH8LmECcyqd" type="829" open="0"/>
<listitem id="uNC1udGnuzN2S" type="829" open="0"/>
<listitem id="ub2aLimnOvCc8" type="829" open="0"/>
<listitem id="uTDfsr4Knx3AZ" type="829" open="0"/>
<listitem id="ufJzUkPpx5QnH" type="829" open="0"/>
<listitem id="RoHoEUz0UZaO" type="829" open="1"/>
<listitem id="uMMCCegdWRMed" type="829" open="0"/>
<listitem id="gkbWE0CWOQFD" type="829" open="1"/>
<listitem id="uIVzscMhthEou" type="829" open="0"/>
<listitem id="uI4uVfXWHwlj8" type="829" open="0"/>
<listitem id="unGP2JF0ACOa5" type="829" open="0"/>
<listitem id="uJPH4z4moUrAV" type="829" open="1"/>
<listitem id="uvkDnW2TlWh7K" type="829" open="1"/>
<listitem id="uT7ZNi38azbf5" type="829" open="1"/>
<listitem id="uVxgjODi2MBCq" type="829" open="1"/>
<listitem id="uRq5pJ7Ak7Ey7" type="829" open="1"/>
</listitem>
<listitem id="dzlPCiVfMhDw" type="803" open="1">
<listitem id="AP2Jw6O9SyPl" type="803" open="0">
@ -1131,6 +1218,7 @@
<listitem id="u46jLezHhgh92" type="815" open="0"/>
</listitem>
<listitem id="ubYkCE7vQXUGD" type="813" open="1">
<listitem id="uTdaJt179nU9j" type="815" open="0"/>
<listitem id="u0MVfw1jTGLqj" type="815" open="0"/>
<listitem id="uBzHrBd7C8T8g" type="815" open="0"/>
</listitem>
@ -1144,12 +1232,15 @@
</listitem>
<listitem id="u5kuKJrlM1zly" type="813" open="1">
<listitem id="usMJpb2kIIUEL" type="815" open="0"/>
<listitem id="uCyAVPudYbQe3" type="816" open="0"/>
<listitem id="uZN3PmvFPlSdS" type="815" open="0"/>
<listitem id="u77HNh6ntNOnH" type="814" open="0"/>
<listitem id="uzdgBeH9fii8b" type="815" open="0"/>
<listitem id="utgdUI6xmJ5NM" type="815" open="0"/>
</listitem>
<listitem id="u99leNLtBz2zk" type="813" open="1">
<listitem id="u0RVaQUf6Iogp" type="815" open="0"/>
<listitem id="uIqGRQaOClVH1" type="815" open="0"/>
</listitem>
<listitem id="uf10mauSZTRhO" type="813" open="1">
<listitem id="ulXYOC6H67SU5" type="815" open="0"/>
<listitem id="uOnkCNjLPCxXk" type="815" open="0"/>
@ -1166,11 +1257,13 @@
</listitem>
<listitem id="uSdMfvm7i7gGI" type="813" open="1">
<listitem id="ucAptBFJopqZY" type="814" open="0"/>
<listitem id="uHC0fucKtP5ko" type="815" open="0"/>
<listitem id="uQEgCpAllbbm3" type="815" open="0"/>
<listitem id="uD216HGDrEbGk" type="815" open="0"/>
<listitem id="uhMQiJD96kEuB" type="815" open="0"/>
</listitem>
<listitem id="uCRIwrHyUI7XP" type="807" label="OutputSlot_components" open="0"/>
<listitem id="u7TfqV7QmzKve" type="810" label="OutputSlot_sequence" open="0"/>
<listitem id="uMC7JhfSjNmhE" type="813" open="1">
<listitem id="uzGwUeh1xLb5s" type="815" open="0"/>
<listitem id="ufYZEWmf1wJdB" type="815" open="0"/>
@ -1198,8 +1291,5 @@
</listitem>
</listitem>
</listview>
<codegeneration>
<codegenerator language="C++"/>
</codegeneration>
</xmi:Extension>
</xmi:XMI>

30
wiki/renderengine.html
View file

@ -1240,10 +1240,10 @@ At this point, a separation is introduced into the //local coordinator// (which
There are only limited sanity checks, and they can be expected to be optimised away for production builds.
The render processing is assumed to proceed along preconfigured processing pipelines, which are instantiated from a »blueprint« -- and the [[Builder]] is responsible to arrange this calculation prototype in such a way, that only valid data accesses are possible. The processing functions and the buffer descriptors are preconfigured to match up.</pre>
</div>
<div title="BufferManagement" modifier="Ichthyostega" created="201109151420" modified="202605300050" tags="Rendering Player spec draft" changecount="4">
<div title="BufferManagement" modifier="Ichthyostega" created="201109151420" modified="202605311748" tags="Rendering Player spec draft" changecount="11">
<pre>Buffers are used to hold the media data for processing and output. Within the Lumiera RenderEngine and [[Player]] subsystem, we use some common concepts to handle the access and allocation of working buffers. Yet this doesn't imply having only one central authority in charge of every buffer -- such an approach wouldn't be possible (due to collaboration with external systems) and wouldn't be desirable either. Rather, there are some common basic usage //patterns// -- and there are some core interfaces used throughout the organisation of the rendering process.
Mostly, the //client code,// i.e. code in need of using buffers, can access some BufferProvider, thereby delegating the actual buffer management. This binds the client to adhere to kind of a //buffer access protocol,// comprised of the ''announcing'', ''locking'', optionally ''attaching'' and finally the ''releasing'' steps. The actual implementation backing these operations is a matter of configuration, which will be setup as part of the ''build process'', when the Render Node network is created.
Mostly, the //client code,// i.e. code in need of using buffers, can access some BufferProvider, thereby delegating the actual buffer management. This binds the client to adhere to kind of a //buffer access protocol,// comprised of the ''announcing'', ''locking'', and finally the ''releasing'' steps. The actual implementation to back these operations is a matter of configuration, and will be setup as part of the ''build process'', when the Render Node network is created.
!usage situations
;rendering
@ -1260,8 +1260,18 @@ Mostly, the //client code,// i.e. code in need of using buffers, can access some
:whenever a calculated result may be of further interest, beyond the immediate need triggering the calculation, it might be eligible for caching.
:The Lumiera ''frame cache'' is a special BufferProvider, maintaining a larger pool of buffers which can be pinned and kept around for some time,
:accommodating limited resources and current demand for fresh result buffers.
;output proxy
:this is a special flavour, and is tightly integrated into the OutputSlot implementation: the client obtains a {{{DataSink}}} handle for each feed; when initiateing the output of one frame, a BuffHandle is returned -- which however is backed by a special {{{OutputBufferProxy}}} that translates the client interactions into calls to the {{{OutputSlot::Connection}}} interface. The latter abstracts the access to the underlying output technology.
;test setup
:a //naive// implementation is used for unit-tests: each buffer request is simply allocated from the heap and this memory is not released or re-used, which allows to verify memory content after invoking the test subject.
!Buffer handling
The management of buffer memory is a major cross-cutting concern in the RenderEngine.This topic encompasses several aspects, since it is necessary to supply the right kind (size) of buffer, to mark a place in the [[render node graph|LowLevelModel]] to use such a //buffer type//, yet also to satisfy the demand for buffer memory that accrues concurrently, as the [[workers|SchedulerWorker]] process a constant flow of [[render jobs|RenderJob]]. Furthermore, the //state// of each individual buffer must be //tracked// as part of the BufferMetadata, since usage of a buffer proceeds through several //phases// (&amp;rarr; the operations outlined at the BufferProvider interface).
A far reaching trait of the Lumiera architecture is the decision to //pre-arrange all possible computations// in the given situation into a ''network of nodes''. Within this framework, the BuffHandle plays the role of a junction point to separate and connect the [[processing logic|NodeOperationProtocol]] from the backing services and the management of resources. The render computation does not need to know how buffers are organised. Each worker can use the //buffer type descriptor// {{{BuffDescr}}} to claim a buffer for use. Furthermore, at the start of each job, an expected maximum capacity simultaneously required is //announced//, based on static reasoning over the render node graph. The implementation of buffer handling relies on thread-local services to handle such requests within a local scope as far as possible.
Allocations are the sole responsibility of the central {{{EngineBufferManager}}} -- yet demand for buffer space is accrued in the local memory pools for each worker. To the extent possible, demand and actual allocations are exchanged by asynchronous messaging, to avoid contention on shared locks when accessing the central services. After usage, a buffer is retained in the thread-local pool, and marked with a //score// whenever it can be re-used to satisfy another demand. It is certainly preferable to re-use a buffer available locally, even when this buffer is too large; but it will get a lower score as when the buffer is a perfect match. Buffers that do not score as well are returned on a tight schedule through the message queue. Interestingly, the central {{{EngineBufferManager}}} does not operate on its own -- since the overall design of the Render Engine avoids //dedicated »service threads«//. The rationale is that such dedicated threads would have to be squeezed into the distribution of work onto the cores, running danger to decrease the cache locality and overthrow the pre-established schedule. Rather, the necessary management work is accrued in small chunks and directly integrated into the processing of some job, that just happens to hit an immediate unsatisfied demand for memory.
</pre>
</div>
<div title="BufferMetadata" modifier="Ichthyostega" created="201109240004" modified="202602152125" tags="spec Rendering draft" changecount="3">
@ -5318,7 +5328,7 @@ And this raises another intricate question of design: //shall {{{Connection}}} b
This would be a very elegant, and modern solution, offering much flexibility for the Implementer of said {{{Connection}}}. The {{{OutputBufferProxy}}} could be templated to that {{{Connection}}} type and thus allow the optimiser to inline and reduce the callback functionality. However -- C++ concepts are a rather new and arcane feature, as they rely on very special syntax and semantics that still requires some time in practical use to catch on and prove its viability. A further objection that can be raised is the fact that compliance to a concept leaves no traces within the implementation -- quite contrary to a classical ~OO-style interface, where the implementation is very obviously marked as such. These considerations bring me to the decision to //reject the use of a concept// here, and to rely on a conventional interface for {{{Connection}}}. Notably it can be expected that new kinds of connection will be added frequently, and so the task for a developer not familiar with all fine points of this design should be reasonably straight forward: „You have to implement the {{{Connection}}} interface“
</pre>
</div>
<div title="OutputSlotImpl" modifier="Ichthyostega" created="201107102343" modified="202603222343" tags="spec operational" changecount="5">
<div title="OutputSlotImpl" modifier="Ichthyostega" created="201107102343" modified="202605312031" tags="spec operational" changecount="10">
<pre>OutputSlot is an abstraction, allowing unified treatment of various physical output connections from within the render jobs.
Each distinct output capability must be registered through an OutputManager. When a client wants to output data, it obtains a suitable OutputSlot through the OutputDirector. This OutputSlot is created and initialised properly for this single use by the {{{OutputManager}}} in charge for that kind of output capability; notably it must be outfitted with an actual implementation of the {{{OutputSlot::Allocation}}} interface, and typically {{{OutputSlot::AllocState&lt;CON&gt;}}} will be used for that purpose.
@ -5327,7 +5337,7 @@ So actual knowledge regarding the underlying technology is confined to the »dri
The client code interacts with the output data buffer through a BuffHandle as front-end. This access scheme is similar to what is used by the generic BufferProvider within the Render Engine. To enable this setup, the OutputSlot embeds a //proxy {{{BufferProvider}}}// and uses a preconfigured buffer (type) descriptor for each connection, which also includes information about the size of the buffer. To start work on a new frame, the client invokes the {{{DataSink}}}, which actually is a functor, with a signature {{{BuffHandle(FrameID)}}}. This call delegates through the proxy {{{BufferProvider}}} ends up calling into {{{Connection::claimBufferFor(frameNr)}}}.
!operation steps
[&gt;img[Sequenz of output data exchange steps|uml/fig145157.png]]As mentioned, the OutputSlot defines a nested ''interface {{{Connection}}}'', with standard operations defined as virtual functions. Each connection technology is expected somehow to support a sequence of actual steps in a ''data exchange protocol''.
As mentioned, the OutputSlot defines a nested ''interface {{{Connection}}}'', with standard operations defined as virtual functions. Each connection technology is expected somehow to support a sequence of actual steps in a ''data exchange protocol''.
;claimBufferFor()
:claims the specified buffer for exclusive use by the client.
:Client may now generate output data into that buffer.
@ -5339,7 +5349,7 @@ The client code interacts with the output data buffer through a BuffHandle as fr
:effectively redundant after the client has invoked {{{emit()}}} -- but the client may choose not to do so (when it is foreseeable that the deadline can not reasonably be met); in such cases, the {{{release()}}} call is the only state indication the {{{Connection}}} implementation gets.
:Triggered by the client invoking {{{release()}}}
{{red{WARNING 3/2026 this UML drawing above is outdated}}}
[img[Sequence of output data exchange steps|uml/OutputSlot_sequence.svg]]
!buffer states
While the BufferProvider, used as front-end for the client, abstracts away the actual access to the output buffers and just hands out a [[buffer handle|BuffHandle]], the server side (which here is the concrete output slot and the backing output technology) is allowed to associate and maintain a ''state flag'' with each buffer. The general assumption is that each output cycle for a single frame originates from a single RenderJob and thus happens from a single thread; moreover, a memory barrier can be assumed prior to invoking the next job. This implies that state transitions regarding the BufferMetadata can be mapped to states as seen from the perspective of the {{{Connection}}} implementation:
@ -6285,7 +6295,7 @@ This is the core service provided by the player subsystem. The purpose is to cre
:any details of this processing remain opaque for the clients; even the player subsystem just accesses the EngineFaçade
</pre>
</div>
<div title="PlaybackVerticalSlice" creator="Ichthyostega" modifier="Ichthyostega" created="202303272236" modified="202603212353" tags="overview impl discuss draft" changecount="51">
<div title="PlaybackVerticalSlice" creator="Ichthyostega" modifier="Ichthyostega" created="202303272236" modified="202605311616" tags="overview impl discuss draft" changecount="52">
<pre>//Integration effort to promote the development of rendering, playback and video display in the GUI//
This IntegrationSlice was started in {{red{2023}}} as [[Ticket #1221|https://issues.lumiera.org/ticket/1221]] to coordinate the completion and integration of various implementation facilities, planned, drafted and built during the last years; this effort marks the return of development focus to the lower layers (after years of focussed UI development) and will implement the asynchronous and time-bound rendering coordinated by the [[Scheduler]] in the [[Vault|Vault-Layer]]
@ -6332,7 +6342,9 @@ __February.25__: built extended verification mechanisms, including some Node met
__January.26__: During the last nine months, unfortunately I was occupied with generic clean-up, upgrade, infrastructure and research work -- and so there was ''no progress'' regarding the PlaybackVerticalSlice. Just before that recess, an important breakthrough was achieved: a complete node graph was built and invoked end to end in a unit test setting. The further integration up to a RenderJob invocation is still blocked by some yet unresolved [[design mismatch (#1395)|https://issues.lumiera.org/ticket/1395]] related to the //»BufferProvider Protocol«// vs the //»OutputSlot Protocol«//; this is where I'll pick up the development work stalled almost a year ago.
__March.26__: Meanwhile I was able to get at the root of the confusion related to BufferProvider and OutputSlot. This insight allows to rectify and realign the architecture, while largely keeping the APIs and both »Protocols« intact. As part of this design revalidation, I did an in-depth re-assessment of buffer metadata handling and got a much better understanding of the requirements for an actual buffer manager implementation -- and it is clear now that at least such a basic implementation is required to achieve a first engine integration. Furthermore, I was indeed able to build a proxy-BufferProvider that can be used as façade within the OutputSlot Protocol, so that both Protocols can be reconciled. The integration of this new proxy implementation necessitates a deeper refactoring within OutputSlot though, leading to a much better and cleaner design overall.
__March.26__: Meanwhile I was able to get at the root of the confusion related to BufferProvider and OutputSlot. This insight allows to rectify and realign the architecture, while largely keeping the ~APIs and both »Protocols« intact. As part of this design revalidation, I did an in-depth re-assessment of buffer metadata handling and got a much better understanding of the requirements for an actual buffer manager implementation -- and it is clear now that at least such a basic implementation is required to achieve a first engine integration. Furthermore, I was indeed able to build a proxy-BufferProvider that can be used as façade within the OutputSlot Protocol, so that both Protocols can be reconciled. The integration of this new proxy implementation necessitates a deeper refactoring within OutputSlot though, leading to a much better and cleaner design overall.
__May.26__: building upon the insight gained through the preceding design rework, a production-grade buffer memory management scheme could be devised. It features thread-local back-end services for the two »pillars« supporting the implementation of the BufferProvider API. These stateful per-worker services are complemented in both cases by a engine-level central service. Notably, for the {{{BufferStore}}}, which relates to the handling of memory resources, an asynchronous messaging was established to send allocated buffers in response to local demand. The usage of resources in each {{{LocalMemPool}}} is accounted with a score to enable heuristic clean-up of rarely used memory blocks, sending them back to the central {{{EngineBufferManager}}} through a message queue. The reworked OutputSlot has been integrated seamlessly into this framework, and a preliminary load test demonstrates safe operation under pressure.
!Decisions
;Scheduler
@ -7100,7 +7112,7 @@ Prerequisite data for the media calculations can be considered just part of that
* all it needs to know is the ''effective nominal time'' and an ''invocation instance ID''
</pre>
</div>
<div title="RenderMechanics" modifier="Ichthyostega" created="200806030230" modified="202501040430" tags="Rendering operational rewrite" changecount="9">
<div title="RenderMechanics" modifier="Ichthyostega" created="200806030230" modified="202605311656" tags="Rendering operational rewrite" changecount="10">
<pre>At architecure level, the render process is sufficiently characterized by the ''pull principle'', regarding dependencies, processing function and the [[»Render Node operation protocol«|NodeOperationProtocol]]. Yet at the level of actual operations and interactions, several intricate details become relevant, especially //how to manage the buffers// and where to provide additional storage for working data.
{{red{⚠ In-depth rework underway as of 12/2024...}}}
^^┅┅┅┅┅┅the following text is ''superseded''┅┅┅┅┅┅┅┅┅^^
@ -7118,7 +7130,7 @@ On the other hand, the processing function within the individual node needs to b
Not everything can be preconfigured though. The pull principle opens the possibility for the node to decide on a per call base what predecessor(s) to pull (if any). This decision may rely on automation parameters, which thus need to be accessible prior to requesting the buffer(s). Additionally, in a later version we plan to have the node network calculate some control values for adjusting the cache and backend timings &amp;mdash; and of course at some point we'll want to utilize the GPU, resulting in the need to feed data from our processing buffers into some texture representation.
!buffer management
{{red{NOTE 9/11: the following is partially obsolete and needs to be rewritten}}} &amp;rarr; see the BufferTable for details regarding new buffer management...
{{red{NOTE 9/11: the following is partially obsolete and needs to be rewritten}}} &amp;rarr; see the BufferProvider for details regarding new buffer management...
...

597
wiki/thinkPad.ichthyo.mm
View file

@ -116089,6 +116089,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<linktarget COLOR="#fe512a" DESTINATION="ID_799936512" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_177101552" SOURCE="ID_1641863868" STARTARROW="None" STARTINCLINATION="-1254;84;"/>
<icon BUILTIN="bell"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238814245" ID="ID_1906573964" MODIFIED="1780155137456" TEXT="Gefahr: Output-Connection mu&#xdf; threadsafe sein">
<linktarget COLOR="#fe512a" DESTINATION="ID_1906573964" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_1581776573" SOURCE="ID_506159225" STARTARROW="None" STARTINCLINATION="-1048;59;"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
<node BACKGROUND_COLOR="#e2caa2" COLOR="#990000" CREATED="1729956600896" ID="ID_988254887" MODIFIED="1729956915005" STYLE="fork" TEXT="Probleme">
<edge COLOR="#b14253" STYLE="sharp_linear"/>
@ -116110,6 +116114,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<linktarget COLOR="#fe512a" DESTINATION="ID_149038061" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_680474771" SOURCE="ID_1105815886" STARTARROW="None" STARTINCLINATION="-891;49;"/>
<icon BUILTIN="bell"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238814245" ID="ID_742422075" MODIFIED="1780157185846" TEXT="Problem: Buffer-Metadata sammeln sich an">
<linktarget COLOR="#fe512a" DESTINATION="ID_742422075" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_1922286656" SOURCE="ID_560462629" STARTARROW="None" STARTINCLINATION="-862;48;"/>
<icon BUILTIN="bell"/>
</node>
</node>
<node BACKGROUND_COLOR="#e2caa2" COLOR="#990000" CREATED="1729956600896" ID="ID_1648467568" MODIFIED="1729956915005" STYLE="fork" TEXT="Ergebnis">
<edge COLOR="#b14253" STYLE="sharp_linear"/>
@ -117383,7 +117391,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</body>
</html></richcontent>
<arrowlink COLOR="#ae0f58" DESTINATION="ID_98767082" ENDARROW="Default" ENDINCLINATION="-622;-143;" ID="Arrow_ID_747040279" STARTARROW="None" STARTINCLINATION="-301;114;"/>
<linktarget COLOR="#ce2ca4" DESTINATION="ID_588438295" ENDARROW="Default" ENDINCLINATION="-1824;71;" ID="Arrow_ID_1583870066" SOURCE="ID_310075674" STARTARROW="None" STARTINCLINATION="-1484;-73;"/>
<linktarget COLOR="#2c65ce" DESTINATION="ID_588438295" ENDARROW="Default" ENDINCLINATION="-1824;71;" ID="Arrow_ID_1583870066" SOURCE="ID_310075674" STARTARROW="None" STARTINCLINATION="-1484;-73;"/>
<icon BUILTIN="smily_bad"/>
<node COLOR="#6b2f01" CREATED="1765477893150" ID="ID_1841000105" MODIFIED="1765477957923" TEXT="das sieht nach einem &#xbb;Knoten&#xab; aus...">
<font NAME="SansSerif" SIZE="10"/>
@ -120562,7 +120570,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1771445380969" FOLDED="true" ID="ID_1703778866" MODIFIED="1774125003754" TEXT="Type-Refinement fehlt">
<linktarget COLOR="#b43f57" DESTINATION="ID_1703778866" ENDARROW="Default" ENDINCLINATION="-1037;-26;" ID="Arrow_ID_1563102453" SOURCE="ID_1813249595" STARTARROW="None" STARTINCLINATION="-107;797;"/>
<icon BUILTIN="hourglass"/>
<node BACKGROUND_COLOR="#fafe99" COLOR="#b10652" CREATED="1771465736392" ID="ID_983442728" MODIFIED="1771465865302" TEXT="Vorsicht: bekanntes Problem mit der TypeHandler-Identit&#xe4;t">
<node BACKGROUND_COLOR="#fafe99" COLOR="#b10652" CREATED="1771465736392" ID="ID_983442728" MODIFIED="1780159764871" TEXT="Vorsicht: bekanntes Problem mit der TypeHandler-Identit&#xe4;t">
<arrowlink COLOR="#f3173a" DESTINATION="ID_1884464720" ENDARROW="Default" ENDINCLINATION="650;39;" ID="Arrow_ID_125159421" STARTARROW="None" STARTINCLINATION="838;36;"/>
<icon BUILTIN="messagebox_warning"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1771466249756" HGAP="29" ID="ID_1350706280" MODIFIED="1771466286391" TEXT="dieses neue API w&#xe4;re gradezu eine Einladung hier ins Messer zu laufen" VSHIFT="13">
@ -124772,6 +124780,9 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1711550954124" ID="ID_1284191800" MODIFIED="1711550960190" TEXT="Untersuchungen von Benny">
<icon BUILTIN="pencil"/>
<node COLOR="#435e98" CREATED="1780158808936" ID="ID_729730347" MODIFIED="1780158832652" TEXT="dabei kam (nur) heraus: GStreamer ist problematisch">
<font NAME="SansSerif" SIZE="11"/>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1711551301631" ID="ID_738125022" MODIFIED="1711551484196" TEXT="f&#xfc;r den Test-Aufbau einbinden">
<arrowlink COLOR="#fe160d" DESTINATION="ID_920789803" ENDARROW="Default" ENDINCLINATION="435;-485;" ID="Arrow_ID_370130803" STARTARROW="None" STARTINCLINATION="-1332;116;"/>
@ -143681,12 +143692,12 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1770827570269" ID="ID_1714212607" MODIFIED="1770829554020" TEXT="gr&#xfc;nden: Render-Buffer-Management">
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1770827570269" ID="ID_1714212607" MODIFIED="1780191270598" TEXT="gr&#xfc;nden: Render-Buffer-Management">
<linktarget COLOR="#f6e1c2" DESTINATION="ID_1714212607" ENDARROW="Default" ENDINCLINATION="-1996;129;" ID="Arrow_ID_1287950435" SOURCE="ID_83307439" STARTARROW="None" STARTINCLINATION="-2318;330;"/>
<icon BUILTIN="flag-yellow"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1770827599588" ID="ID_310075674" MODIFIED="1770827807325" TEXT="Vorarbeiten: Protokoll-Implementierungen &#xbb;in den Griff bekommen&#xab;">
<arrowlink COLOR="#ce2ca4" DESTINATION="ID_588438295" ENDARROW="Default" ENDINCLINATION="-1824;71;" ID="Arrow_ID_1583870066" STARTARROW="None" STARTINCLINATION="-1484;-73;"/>
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#b2d2d9" COLOR="#338800" CREATED="1770827599588" ID="ID_310075674" MODIFIED="1780260154487" TEXT="Vorarbeiten: Protokoll-Implementierungen &#xbb;in den Griff bekommen&#xab;">
<arrowlink COLOR="#2c65ce" DESTINATION="ID_588438295" ENDARROW="Default" ENDINCLINATION="-1824;71;" ID="Arrow_ID_1583870066" STARTARROW="None" STARTINCLINATION="-1484;-73;"/>
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1734654001763" ID="ID_1148074170" MODIFIED="1770828023989" TEXT="Feststellung: rein konzeptionell sind die Protokolle in Ordnung">
<linktarget COLOR="#263bd0" DESTINATION="ID_1148074170" ENDARROW="Default" ENDINCLINATION="555;-1157;" ID="Arrow_ID_1408757425" SOURCE="ID_900623108" STARTARROW="None" STARTINCLINATION="16;273;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
@ -143759,11 +143770,47 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</html></richcontent>
<arrowlink COLOR="#796369" DESTINATION="ID_78273441" ENDARROW="Default" ENDINCLINATION="-357;-789;" ID="Arrow_ID_1295978639" STARTARROW="None" STARTINCLINATION="-470;45;"/>
</node>
<node CREATED="1780260378331" ID="ID_803703902" MODIFIED="1780260998240" TEXT="2026 : Prototyp production-grade Buffer-Management">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Aufbauend auf die Einsichten aus der Design-Arbeit zu &#187;BufferProvider Protocol&#171; und &#187;OutputSlot Protocol&#171; habe ich nun eine Gesamt-Implementierung entworfen f&#252;r den Betrieb in einem massive-concurrent-Environment. Dabei hatte ich zun&#228;chst die Idee weiterverfolgt, die Buffer-Metadaten auszubauen zu einem Informationstr&#228;ger zur Koordinierung der internen Verwaltung. Nach erheblichen gedanklichen M&#252;hen bin ich aber zu dem Schlu&#223; gekommen, <i>da&#223; diese Idee mehr Komplikationen und Komplexit&#228;ten schafft, als Klarheit stiftet.</i>&#160;Damit bleiben die Buffer-Metadaten vorerst berschr&#228;nkt auf den Buffer-Typ (+Typ-Handler), sowie das State-Tracking.
</p>
<p>
Au&#223;erdem hat sich nun die Frage gestellt bez&#252;glich Austausch &#252;ber Thread-Grenzen hinweg. Ich habe nun generell dieses Buffer-Management organisiert als eine Menge von thread-lokalen Services, die jeweils mit einem zentralen back-End-Service kommunizieren. Im Falle der BufferMetadaten sind das nun die LocalBufferStage (Implementierung), die das jeweilige LocalSlice&lt;BufferMetadata&gt; tr&#228;gt, sowie der zentrale Setvice EngineBufferMetadata. Es kommt dabei zu einer up/down-Synchronisation an zwei wohldefinierten Punkten &#8212; und in diesem Fall gen&#252;gt mir (vorerst) ein globales Locking der EngineBufferMetadata, da ich diese SItuation <i>als selten einsch&#228;tze.</i>&#160;
</p>
<p>
</p>
<p>
Die <b>Allokationen</b>&#160;sind somit <i>komplett getrennt von den Buffer-Metadaten.</i>&#160;Sie werden minimal dargestellt als {Buffer*, size_t} und in dieser Form &#252;ber asynchrone Queues verschickt
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#666a8e" DESTINATION="ID_804866125" ENDARROW="Default" ENDINCLINATION="-736;0;" ID="Arrow_ID_831131977" STARTARROW="None" STARTINCLINATION="-288;15;"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1769303576693" ID="ID_399072135" MODIFIED="1770828085997" TEXT="die Implementierung ist nicht ausreichend auf Zustands&#xfc;berg&#xe4;nge zentriert">
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#e0c3a5" COLOR="#98014b" CREATED="1780159527218" ID="ID_340145386" MODIFIED="1780159578471" TEXT="die Buffer-Metadaten bleiben latent problematisch">
<font NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="bell"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780159639265" ID="ID_1182218786" MODIFIED="1780159715461" TEXT="undel&#xf6;stes Problem mit der TypeHandler-Identit&#xe4;t">
<arrowlink COLOR="#ab053a" DESTINATION="ID_1218434069" ENDARROW="Default" ENDINCLINATION="163;-117;" ID="Arrow_ID_1762052959" STARTARROW="None" STARTINCLINATION="1232;71;"/>
<icon BUILTIN="broken-line"/>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1771465174999" ID="ID_1795268003" LINK="https://issues.lumiera.org/ticket/1411" MODIFIED="1780159772916" TEXT="#1411">
<icon BUILTIN="flag-yellow"/>
</node>
</node>
<node CREATED="1780159658303" ID="ID_1053543218" MODIFIED="1780159668334" TEXT="Design ist noch nicht wirklich begr&#xfc;ndet"/>
<node CREATED="1780159586745" ID="ID_22336224" MODIFIED="1780159745457" TEXT="wir akkummulieren Metadaten">
<arrowlink COLOR="#ec4f6b" DESTINATION="ID_923089948" ENDARROW="Default" ENDINCLINATION="438;-406;" ID="Arrow_ID_507520861" STARTARROW="None" STARTINCLINATION="449;40;"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1780099972923" ID="ID_1019040694" MODIFIED="1780100051757" TEXT="eine neutralere Beurteilung wird erst viel sp&#xe4;ter m&#xf6;glich sein">
<arrowlink COLOR="#675e8f" DESTINATION="ID_186086868" ENDARROW="Default" ENDINCLINATION="-794;-26;" ID="Arrow_ID_1805633100" STARTARROW="None" STARTINCLINATION="-758;36;"/>
<icon BUILTIN="hourglass"/>
@ -143916,7 +143963,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</body>
</html></richcontent>
</node>
<node CREATED="1773685436937" ID="ID_1194997795" MODIFIED="1773685524347" TEXT="Buffer-Metadaten werden mutma&#xdf;lich auch vom Storage-Backend mitverwendet">
<node COLOR="#5b280f" CREATED="1773685436937" ID="ID_1194997795" MODIFIED="1780147762985" TEXT="Buffer-Metadaten werden mutma&#xdf;lich auch vom Storage-Backend mitverwendet">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -143925,13 +143972,70 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</p>
</body>
</html></richcontent>
<icon BUILTIN="button_cancel"/>
<node CREATED="1780147764617" ID="ID_387490859" MODIFIED="1780147866121" TEXT="sieht jetzt nicht mehr danach aus....">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...nach Aufbau der production-Grade-Implementierung des BufferProviders; hatte da eine lange (schmerzhafte) Diskussion mit mir selber gef&#252;hrt, und bin zu dem Schlu&#223; gekommen, das Thema Allokation doch komplett in-sich abgeschlossen aufzubauen
</p>
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1780147871469" ID="ID_1632085997" MODIFIED="1780147888438" TEXT="immer noch offen: wie pa&#xdf;t das mit dem Cache zusammen?">
<icon BUILTIN="bell"/>
</node>
</node>
<node CREATED="1773703954354" ID="ID_1415408255" MODIFIED="1773703991156" TEXT="m&#xf6;glicherweise will man gemeinsame Metadaten-Tabellen">
<linktarget COLOR="#76516c" DESTINATION="ID_1415408255" ENDARROW="Default" ENDINCLINATION="779;39;" ID="Arrow_ID_1408352744" SOURCE="ID_340628735" STARTARROW="None" STARTINCLINATION="468;17;"/>
</node>
<node COLOR="#338800" CREATED="1780147902066" ID="ID_523819324" LINK="#ID_1285006287" MODIFIED="1780147976445" TEXT="Mai 26: wir haben jetzt ein System von globalen / thread-lokalen Metadaten"/>
</node>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1773686351857" ID="ID_867612305" MODIFIED="1773686475190" TEXT="Performance und Zusammenspiel mit dem Betriebszustand?">
<linktarget COLOR="#794397" DESTINATION="ID_867612305" ENDARROW="Default" ENDINCLINATION="-1231;58;" ID="Arrow_ID_535246973" SOURCE="ID_339106431" STARTARROW="None" STARTINCLINATION="-148;960;"/>
<icon BUILTIN="help"/>
<node CREATED="1780156822353" ID="ID_1092563753" MODIFIED="1780157027405" TEXT="wir sammeln &#xbb;einmal&#xab;-Metadaten beim Output">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
F&#252;r jeden neuen Output-Vorgang wird ein Satz Connection-Objekte erstellt, und f&#252;r jedes von ihnen ein Buffer-Typ, mit eingebettem Pointer im LocalTag. Diese Buffer-Typen werden massiv verwendet, f&#252;r jeden Frame, solange dieser Output l&#228;uft (Buffer-Lifecycle). Hierf&#252;r propagieren sie auch zun&#228;chst vom Session-Thread in den globalen Store, und von dort in die jeweiligen thread-local BufferMetadata.
</p>
<p>
</p>
<p>
Aber nachdem diese Connection geschlossen wird, liegen diese N typen weiterhin in den verteilten BufferMetadata-Instanzen herum
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#cf0429" DESTINATION="ID_816514752" ENDARROW="Default" ENDINCLINATION="45;-685;" ID="Arrow_ID_1101777071" STARTARROW="None" STARTINCLINATION="533;32;"/>
<node CREATED="1780157041668" ID="ID_923089948" MODIFIED="1780159745457" TEXT="das mit dem Sammeln gilt auch f&#xfc;r alle Buffer-Typen allgemein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...aber bei diesen kann man davon ausgehen, da&#223; sich das irgendwann einpendelt...
</p>
</body>
</html></richcontent>
<linktarget COLOR="#ec4f6b" DESTINATION="ID_923089948" ENDARROW="Default" ENDINCLINATION="438;-406;" ID="Arrow_ID_507520861" SOURCE="ID_22336224" STARTARROW="None" STARTINCLINATION="449;40;"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238837562" HGAP="173" ID="ID_560462629" MODIFIED="1780157185846" STYLE="bubble" TEXT="problematische Akkummulation von Metadaten" VSHIFT="27">
<edge COLOR="#ff5d00" STYLE="sharp_linear"/>
<arrowlink COLOR="#fe512a" DESTINATION="ID_742422075" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_1922286656" STARTARROW="None" STARTINCLINATION="-862;48;"/>
<icon BUILTIN="bell"/>
<node CREATED="1721239003353" ID="ID_945962387" MODIFIED="1780157218560" STYLE="fork" TEXT="replizierte Storage &#x2014; man kann nicht aufr&#xe4;umen">
<font NAME="SansSerif" SIZE="8"/>
</node>
</node>
</node>
</node>
</node>
<node CREATED="1780260195236" ID="ID_761417774" MODIFIED="1780260206879" TEXT="Allokations-Management">
<node COLOR="#435e98" CREATED="1780260208251" ID="ID_9231521" MODIFIED="1780260305579" TEXT="Heuristik zum Aufr&#xe4;umen der lokalen Pools">
<arrowlink COLOR="#67a5cd" DESTINATION="ID_851031995" ENDARROW="Default" ENDINCLINATION="-325;-25;" ID="Arrow_ID_857205470" STARTARROW="None" STARTINCLINATION="531;32;"/>
<icon BUILTIN="idea"/>
</node>
</node>
</node>
@ -143951,7 +144055,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<node CREATED="1778113600754" ID="ID_688748631" MODIFIED="1778113686162" TEXT="Spezial-Variante: Input-BufferProvider">
<arrowlink COLOR="#4359d9" DESTINATION="ID_1131259858" ENDARROW="Default" ENDINCLINATION="-1448;-166;" ID="Arrow_ID_863939341" STARTARROW="None" STARTINCLINATION="-1197;90;"/>
<node CREATED="1778113691625" ID="ID_1816417895" MODIFIED="1778113700651" TEXT="Interface / Verwendung">
<node CREATED="1778113708111" ID="ID_1426869397" MODIFIED="1779807245515" TEXT="f&#xfc;gt sich nahtlos ein">
<node CREATED="1778113708111" ID="ID_1426869397" MODIFIED="1780196757484" TEXT="f&#xfc;gt sich nahtlos ein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -143960,7 +144064,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</p>
</body>
</html></richcontent>
<linktarget COLOR="#850b20" DESTINATION="ID_1426869397" ENDARROW="Default" ENDINCLINATION="59;906;" ID="Arrow_ID_881098297" SOURCE="ID_970184894" STARTARROW="None" STARTINCLINATION="-845;-127;"/>
<linktarget COLOR="#850b20" DESTINATION="ID_1426869397" ENDARROW="Default" ENDINCLINATION="6;603;" ID="Arrow_ID_881098297" SOURCE="ID_970184894" STARTARROW="None" STARTINCLINATION="-845;-127;"/>
<icon BUILTIN="idea"/>
</node>
<node CREATED="1778115434027" ID="ID_147619275" MODIFIED="1778115455653" TEXT="aber: zus&#xe4;tzliche Konventionen">
@ -144000,14 +144104,14 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1778116492368" ID="ID_847440044" MODIFIED="1778116538951" TEXT="TODO: Struktur der Jobs kl&#xe4;ren">
<arrowlink COLOR="#4b5174" DESTINATION="ID_1679522795" ENDARROW="Default" ENDINCLINATION="28;-1464;" ID="Arrow_ID_934032093" STARTARROW="None" STARTINCLINATION="-552;47;"/>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1778116492368" ID="ID_847440044" MODIFIED="1780241775089" TEXT="TODO: Struktur der Jobs kl&#xe4;ren">
<arrowlink COLOR="#4b5174" DESTINATION="ID_1679522795" ENDARROW="Default" ENDINCLINATION="-100;-627;" ID="Arrow_ID_934032093" STARTARROW="None" STARTINCLINATION="-552;47;"/>
<icon BUILTIN="bell"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1770828120216" ID="ID_1112258994" MODIFIED="1779805233946" TEXT="vorl&#xe4;ufige Implementierung">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1770828120216" ID="ID_1112258994" MODIFIED="1780191257916" TEXT="vorl&#xe4;ufige Implementierung">
<icon BUILTIN="button_ok"/>
<node CREATED="1771434625350" ID="ID_87043838" MODIFIED="1779804039943" TEXT="vorgreifende Vereinfachungen">
<arrowlink COLOR="#1d52cb" DESTINATION="ID_675333491" ENDARROW="Default" ENDINCLINATION="-1038;-32;" ID="Arrow_ID_1903219737" STARTARROW="None" STARTINCLINATION="178;997;"/>
<node COLOR="#5b280f" CREATED="1771434938648" ID="ID_598910343" MODIFIED="1778792994090" TEXT="Anouncements ignorieren und jeweils per Heap allozieren">
@ -144070,8 +144174,9 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#370f69" CREATED="1776195345475" ID="ID_773105612" MODIFIED="1780099646308" TEXT="Problem der Code-Struktur">
<icon BUILTIN="messagebox_warning"/>
<node BACKGROUND_COLOR="#e0e0aa" COLOR="#232066" CREATED="1776195345475" FOLDED="true" ID="ID_773105612" MODIFIED="1780260324757" TEXT="schrittweise eine tragf&#xe4;hige Code-Struktur aufbauen...">
<icon BUILTIN="yes"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1776195352772" ID="ID_865032756" MODIFIED="1776195928687">
<richcontent TYPE="NODE"><html>
<head/>
@ -144181,13 +144286,14 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<node CREATED="1776200398600" ID="ID_1570370873" MODIFIED="1776200451325" TEXT="sub-Typen h&#xe4;ngen an der konkreten Speicher-Adresse (die unique ist)"/>
<node CREATED="1776200454105" ID="ID_1248388353" MODIFIED="1776200473996" TEXT="problematisch sind typ-Keys, und zwar bez&#xfc;glich der Type-Handler"/>
<node CREATED="1776200497774" ID="ID_1039074673" MODIFIED="1776200508694" TEXT="Schlu&#xdf;folgerungen...">
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1776200510094" ID="ID_1218434069" MODIFIED="1776202055802" TEXT="das Identit&#xe4;ts-Problem im Typ-Funktor mu&#xdf; gel&#xf6;st werden">
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1776200510094" ID="ID_1218434069" MODIFIED="1780159763007" TEXT="das Identit&#xe4;ts-Problem im Typ-Funktor mu&#xdf; gel&#xf6;st werden">
<arrowlink COLOR="#f62244" DESTINATION="ID_1884464720" ENDARROW="Default" ENDINCLINATION="929;56;" ID="Arrow_ID_1092187353" STARTARROW="Default" STARTINCLINATION="652;-35;"/>
<linktarget COLOR="#ab053a" DESTINATION="ID_1218434069" ENDARROW="Default" ENDINCLINATION="163;-117;" ID="Arrow_ID_1762052959" SOURCE="ID_1182218786" STARTARROW="None" STARTINCLINATION="1232;71;"/>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1776200560492" ID="ID_394534485" MODIFIED="1776200580572" TEXT="niemals d&#xfc;rfen zwei verschiedene Funktionen den gleichen Hash bekommen"/>
<node CREATED="1776200683846" ID="ID_897159086" MODIFIED="1776200690709" TEXT="erscheint l&#xf6;sbar">
<node CREATED="1776200691825" ID="ID_522566119" MODIFIED="1776200705923" TEXT="entweder indem der Erzeuger eine SpecID mitliefern mu&#xdf;"/>
<node CREATED="1776200706983" ID="ID_99543390" MODIFIED="1776203862174" TEXT="oder indem man auf die Funktor-Identit&#xe4;ten abstellt">
<node CREATED="1776200706983" ID="ID_99543390" MODIFIED="1780159174700" TEXT="oder indem man auf die Funktor-Identit&#xe4;ten abstellt">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -144207,8 +144313,19 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</p>
</body>
</html></richcontent>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780159282877" HGAP="56" ID="ID_1817080344" MODIFIED="1780159387180" TEXT="Vorsicht: Wechselwirkung mit der replizierten Storage f&#xfc;r BufferMetadata" VSHIFT="8">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Bisher liegt der TypeHandler als Value-Objekt in den Metadaten, wird also kopiert zur Replikation; das w&#252;rde mit einer <b>Funktor-Identit&#228;t als Objekt-Identit&#228;t kollidieren</b>
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
<node CREATED="1776202090769" ID="ID_967352308" MODIFIED="1776203851816" TEXT="redundante Duplikate des gleichen Funktors...">
</node>
<node CREATED="1776202090769" ID="ID_967352308" MODIFIED="1776202090769" TEXT="redundante Duplikate des gleichen Funktors...">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
@ -144394,8 +144511,8 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1776204526672" ID="ID_961403309" MODIFIED="1776477618192" TEXT="Prototyping (testgetrieben)">
<icon BUILTIN="pencil"/>
<node COLOR="#338800" CREATED="1776204526672" ID="ID_961403309" MODIFIED="1780191082278" TEXT="Prototyping (testgetrieben)">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1776293021744" ID="ID_290625266" MODIFIED="1776717333143" TEXT="Problem: dieses Setup ist effektiv statisch/global">
<richcontent TYPE="NOTE"><html>
<head/>
@ -144414,7 +144531,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<arrowlink COLOR="#a61032" DESTINATION="ID_808171568" ENDARROW="Default" ENDINCLINATION="11;-94;" ID="Arrow_ID_66477268" STARTARROW="None" STARTINCLINATION="257;14;"/>
<icon BUILTIN="messagebox_warning"/>
</node>
<node COLOR="#338800" CREATED="1776204565654" ID="ID_45614742" MODIFIED="1776522493293" TEXT="generischer Slice">
<node COLOR="#338800" CREATED="1776204565654" FOLDED="true" ID="ID_45614742" MODIFIED="1780191089393" TEXT="generischer Slice">
<icon BUILTIN="button_ok"/>
<node CREATED="1776292208608" ID="ID_1141218614" MODIFIED="1776477482889" TEXT="Zweck: Anbinden eines Slice in einem normalen Objekt-Kontext">
<icon BUILTIN="info"/>
@ -144587,7 +144704,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node COLOR="#338800" CREATED="1776204569932" ID="ID_1285006287" MODIFIED="1776717570113" TEXT="Technologie: lokaler Metadaten-Store">
<node COLOR="#338800" CREATED="1776204569932" FOLDED="true" ID="ID_1285006287" MODIFIED="1780191093167" TEXT="Technologie: lokaler Metadaten-Store">
<linktarget COLOR="#3c578a" DESTINATION="ID_1285006287" ENDARROW="Default" ENDINCLINATION="-27;32;" ID="Arrow_ID_145731778" SOURCE="ID_292130223" STARTARROW="None" STARTINCLINATION="-327;39;"/>
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1776522893322" FOLDED="true" ID="ID_1694212347" MODIFIED="1776717948394" TEXT="BufferMetadata um Migration erweitern">
@ -144771,7 +144888,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node COLOR="#338800" CREATED="1776204694205" ID="ID_1617552510" MODIFIED="1776717871305" TEXT="LocalBufferStage">
<node COLOR="#338800" CREATED="1776204694205" FOLDED="true" ID="ID_1617552510" MODIFIED="1780191096255" TEXT="LocalBufferStage">
<icon BUILTIN="button_ok"/>
<node COLOR="#435e98" CREATED="1776436907819" ID="ID_1105234662" MODIFIED="1776717877295" TEXT="Rolle der RootID kl&#xe4;ren">
<linktarget COLOR="#5b39d7" DESTINATION="ID_1105234662" ENDARROW="Default" ENDINCLINATION="113;-353;" ID="Arrow_ID_8614584" SOURCE="ID_1444097357" STARTARROW="None" STARTINCLINATION="-450;30;"/>
@ -144861,7 +144978,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<icon BUILTIN="idea"/>
</node>
</node>
<node COLOR="#338800" CREATED="1776204702568" ID="ID_1197574712" MODIFIED="1779803959108" TEXT="LocalBufferStore">
<node COLOR="#338800" CREATED="1776204702568" FOLDED="true" ID="ID_1197574712" MODIFIED="1779803959108" TEXT="LocalBufferStore">
<icon BUILTIN="button_ok"/>
<node BACKGROUND_COLOR="#91c1a7" COLOR="#0f5353" CREATED="1776718325330" ID="ID_675333491" MODIFIED="1779804074905" TEXT="in mehreren Schritten eine &#xbb;einfache&#xab; Implementierung aufbauen">
<linktarget COLOR="#1d52cb" DESTINATION="ID_675333491" ENDARROW="Default" ENDINCLINATION="-1038;-32;" ID="Arrow_ID_1903219737" SOURCE="ID_87043838" STARTARROW="None" STARTINCLINATION="178;997;"/>
@ -145739,7 +145856,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</body>
</html></richcontent>
<icon BUILTIN="button_ok"/>
<node COLOR="#338800" CREATED="1776204765269" ID="ID_1404790840" MODIFIED="1776718452275" TEXT="EngineBufferMetadata">
<node COLOR="#338800" CREATED="1776204765269" FOLDED="true" ID="ID_1404790840" MODIFIED="1780191104490" TEXT="EngineBufferMetadata">
<icon BUILTIN="button_ok"/>
<node CREATED="1776605957061" ID="ID_405169256" MODIFIED="1776606058887" TEXT="eigenst&#xe4;ndiger Service">
<richcontent TYPE="NOTE"><html>
@ -145830,7 +145947,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</html></richcontent>
</node>
</node>
<node COLOR="#338800" CREATED="1776204795573" ID="ID_1001789565" MODIFIED="1778800580244" TEXT="EngineBufferManager">
<node COLOR="#338800" CREATED="1776204795573" FOLDED="true" ID="ID_1001789565" MODIFIED="1778800580244" TEXT="EngineBufferManager">
<icon BUILTIN="button_ok"/>
<node CREATED="1778792315684" ID="ID_1791813360" MODIFIED="1778792397575" TEXT="nun doch bereits grunds&#xe4;tzlich fertig implementiert">
<arrowlink COLOR="#1b1ac0" DESTINATION="ID_1998897998" ENDARROW="Default" ENDINCLINATION="15;-85;" ID="Arrow_ID_1964764365" STARTARROW="None" STARTINCLINATION="-438;24;"/>
@ -145844,7 +145961,9 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node CREATED="1776442826894" ID="ID_509761355" MODIFIED="1776442834087" TEXT="OutputSlot mit integrieren">
<node COLOR="#338800" CREATED="1776442826894" FOLDED="true" ID="ID_509761355" MODIFIED="1780191108333" TEXT="OutputSlot mit integrieren">
<linktarget COLOR="#1e4d87" DESTINATION="ID_509761355" ENDARROW="Default" ENDINCLINATION="-54;837;" ID="Arrow_ID_569900076" SOURCE="ID_1395244829" STARTARROW="None" STARTINCLINATION="96;-1313;"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1776442835820" ID="ID_1709918207" MODIFIED="1776442866636" TEXT="der integrierte OutputBufferProxy hat auch eine BufferStage-Implementierung"/>
<node CREATED="1776442867383" ID="ID_1166356526" MODIFIED="1776442917901" TEXT="diese ist bisher hart gecodet &#x2014; k&#xf6;nnte nat&#xfc;rlich (statisch) konfigurierbar sein"/>
<node CREATED="1776442948509" ID="ID_652246892" MODIFIED="1776443208611" TEXT="OutputSlot hinter BuffHandle versteckt &#x27f9; &#xdc;berlegungen zum BufferProvider gelten analog">
@ -145868,11 +145987,369 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</body>
</html></richcontent>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1776443222077" ID="ID_1588377123" MODIFIED="1776443240902" TEXT="AUA! an die Concurrency in OutputSlot habe ich noch gar nicht gedacht">
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1776443222077" ID="ID_1588377123" MODIFIED="1780190732762" TEXT="AUA! an die Concurrency in OutputSlot habe ich noch gar nicht gedacht">
<icon BUILTIN="smily_bad"/>
<node CREATED="1776443274627" ID="ID_1179051881" MODIFIED="1776443293851" TEXT="jeder Frame-Ausgabevorgang kann aus einem anderen Thread kommen"/>
<node CREATED="1776443294663" ID="ID_603938434" MODIFIED="1776443307734" TEXT="allerdings wird niemals der gleiche Frame contended"/>
<node CREATED="1776443311725" ID="ID_1518887346" MODIFIED="1776443326639" TEXT="und der Slot ist f&#xfc;r einen einzigen Play-Proze&#xdf;"/>
<node CREATED="1780152624090" FOLDED="true" ID="ID_1716480866" MODIFIED="1780190827581" TEXT="Analyse der Nutzmuster">
<icon BUILTIN="edit"/>
<node CREATED="1776443311725" ID="ID_1518887346" MODIFIED="1780152704806" TEXT="ein OutputSlot ist f&#xfc;r einen einzigen Play-Proze&#xdf; erstellt">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
damit meine ich eigentlich seine &#187;Identit&#228;t&#171; (es ist ja ein ref-counting smart-Handle). Diese <i>verborgene Identit&#228;t</i>&#160;ist tats&#228;chlich der AllocState&lt;CON&gt;
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780152756832" ID="ID_1262441113" MODIFIED="1780152845829" TEXT="in diesem Moment werden alle Bufer-Descriptors(&#x2259;Typen) auf einen Schlag registriert"/>
<node CREATED="1780152801870" ID="ID_627826119" MODIFIED="1780152831496" TEXT="das passiert (mutma&#xdf;lich) aus dem Session-Thread heraus">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...da es dieser ist, der letztlich einen Play-Proze&#223; aufbaut
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780153846990" ID="ID_629355007" MODIFIED="1780155882883" TEXT="DataSinks sind selber einfache kopierbare Values (allerdings mit ref-count)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...d.h. Kopieren hat (geringf&#252;gige) Kosten und kann den andere Threads, die dieses Handle auch verwenden, ausbremsen. Aber an der Oberfl&#228;che bleibt das verborgen, und es handelt sich um einen einfachen Pointer)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780153963495" ID="ID_1888132144" MODIFIED="1780154002854" TEXT="Worker ruft DataSink auf (f&#xfc;r einen Frame) &#x27f6; bufferDescriptor.lockBuffer (frame);"/>
<node CREATED="1780154045507" ID="ID_1717285049" MODIFIED="1780154057854" TEXT="BufferProvider::lockBuffer (BuffDescr, arg)">
<node CREATED="1780154094986" ID="ID_1752872739" MODIFIED="1780154103267" TEXT="BufferStage::lookup(type)">
<node CREATED="1780154499223" ID="ID_840924385" MODIFIED="1780154515557" TEXT="beim erster Verwendung im Worker: Lock und Sync"/>
<node CREATED="1780154516488" ID="ID_1651500642" MODIFIED="1780154523279" TEXT="sp&#xe4;ter: thread-local lookup"/>
</node>
<node CREATED="1780154104068" ID="ID_1742013252" MODIFIED="1780154113198" TEXT="BufferStore::provideBuffer">
<node CREATED="1780154554186" ID="ID_869466051" MODIFIED="1780154572058" TEXT="ruft (nach cast) die virtuelle Funktion CON::claimBufferFor"/>
<node CREATED="1780154598681" ID="ID_755767118" MODIFIED="1780154608589" TEXT="hier irrelevant"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780154610448" ID="ID_850357201" MODIFIED="1780154727396">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
ABER beachte: CON-Implementation mu&#223; <b>threadsafe</b>&#160;sein
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238837562" HGAP="148" ID="ID_506159225" MODIFIED="1780155137455" STYLE="bubble" TEXT="Problem: Concurrency in der Output-Connection" VSHIFT="44">
<edge COLOR="#ff5d00" STYLE="sharp_linear"/>
<arrowlink COLOR="#fe512a" DESTINATION="ID_1906573964" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_1581776573" STARTARROW="None" STARTINCLINATION="-1048;59;"/>
<arrowlink COLOR="#fe512a" DESTINATION="ID_503976809" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_744367367" STARTARROW="None" STARTINCLINATION="-943;53;"/>
<icon BUILTIN="bell"/>
<node CREATED="1721239003353" ID="ID_280273112" MODIFIED="1780155152634" STYLE="fork" TEXT="das ist &#xfc;berhaupt nicht offensichtlich">
<font NAME="SansSerif" SIZE="8"/>
</node>
<node CREATED="1780155160703" ID="ID_1242289323" MODIFIED="1780155185068" STYLE="fork" TEXT="und sehr un&#xfc;blich!">
<edge COLOR="#ff5d00" STYLE="sharp_linear" WIDTH="thin"/>
<font NAME="SansSerif" SIZE="8"/>
</node>
</node>
</node>
</node>
<node CREATED="1780154119810" ID="ID_1236065579" MODIFIED="1780154128126" TEXT="BufferStage::mark_locked()">
<node CREATED="1780155844247" ID="ID_1144004586" MODIFIED="1780155857918" TEXT="hier stets eine Interaktion im lokalen Metadata-Store"/>
</node>
</node>
<node CREATED="1780156306958" ID="ID_995156023" MODIFIED="1780156316809" TEXT="der Rest l&#xe4;uft dann vergleichbar ab...">
<node BACKGROUND_COLOR="#deae92" COLOR="#990033" CREATED="1780156382380" ID="ID_1577300158" MODIFIED="1780156432277" TEXT="man kann das nicht durch eine globale Instanz ersetzen">
<icon BUILTIN="messagebox_warning"/>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780156433734" ID="ID_1882566000" MODIFIED="1780156451104" TEXT="d.h. die naive-Implementierung ist sogar broken">
<icon BUILTIN="clanbomber"/>
<node CREATED="1780156492073" ID="ID_1362852469" MODIFIED="1780156492073">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
zwar w&#252;rden die Typen zun&#228;chst von einem Thread gemeinsam populiert
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780156495221" ID="ID_381987195" MODIFIED="1780156506520" TEXT="aber dann passieren ganz fragile, concurrent updates"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780156516185" ID="ID_573136962" MODIFIED="1780156556233">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
im Besonderen werden <font color="#d6082e">sub-Typen hinzugef&#252;gt und wieder gel&#246;scht</font>
</p>
</body>
</html></richcontent>
<icon BUILTIN="broken-line"/>
</node>
</node>
<node CREATED="1780156394091" ID="ID_1097392088" MODIFIED="1780156631676" TEXT="aber im verteilt-lokalen System ist das kein wirkliches Problem">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
mit dem gleichen Argument, welches ich generell f&#252;r den BufferManager mache: nach einem initialen <i>Priming</i>&#160;m&#252;&#223;te jeder Worker alsbald alle Daten bei sich haben, und diese dann sehr viel h&#228;ufiger einfach lokal lesen und modifizieren
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1780156323300" ID="ID_1425727154" MODIFIED="1780190894161">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
<b>Fazit</b>: wir brauchen das gleiche Setup wie f&#252;r den generischen BufferManager
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#39378c" DESTINATION="ID_1211313189" ENDARROW="Default" ENDINCLINATION="20;-72;" ID="Arrow_ID_79089719" STARTARROW="None" STARTINCLINATION="-226;8;"/>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
<icon BUILTIN="yes"/>
</node>
</node>
<node COLOR="#338800" CREATED="1780150813403" FOLDED="true" ID="ID_1211313189" MODIFIED="1780190914602" TEXT="Aufgabe &#x27f9; konfigurierbar machen">
<linktarget COLOR="#39378c" DESTINATION="ID_1211313189" ENDARROW="Default" ENDINCLINATION="20;-72;" ID="Arrow_ID_79089719" SOURCE="ID_1425727154" STARTARROW="None" STARTINCLINATION="-226;8;"/>
<icon BUILTIN="yes"/>
<node COLOR="#435e98" CREATED="1780151547498" ID="ID_884953043" MODIFIED="1780190902292" TEXT="inwiefern?">
<icon BUILTIN="help"/>
<node CREATED="1780151553839" ID="ID_997928701" MODIFIED="1780151657988" TEXT="f&#xfc;r Tests wollen wir eine dedizierte BufferMetadata-Instanz und gut is">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Also die &#252;bliche Konfiguration mit direkter Heap-Allokation, so wie das auch f&#252;r das NaiveBufferSetup verwendet wird:
</p>
<p>
<font color="#4a1a65" face="DejaVu Sans Mono" size="9pt"><b>return</b></font><font color="#3a1f18" face="DejaVu Sans Mono" size="9pt">&#160;</font><font color="#535773" face="DejaVu Sans Mono" size="9pt">std</font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">::</font><font color="#000000" face="DejaVu Sans Mono" size="9pt">make_unique</font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">&lt;</font><font color="#535773" face="DejaVu Sans Mono" size="9pt">vault</font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">::</font><font color="#535773" face="DejaVu Sans Mono" size="9pt">mem</font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">::</font><font color="#635e96" face="DejaVu Sans Mono" size="9pt"><b>SimpleBufferStateRegistry</b></font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">&gt;</font><font color="#11123a" face="DejaVu Sans Mono" size="9pt">(</font><font color="#996e62" face="DejaVu Sans Mono" size="9pt"><i>&quot;OutputBufferProxy&quot;</i></font><font color="#11123a" face="DejaVu Sans Mono" size="9pt">)</font><font color="#65533c" face="DejaVu Sans Mono" size="9pt">;</font>
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780151680800" ID="ID_951073767" MODIFIED="1780151744492" TEXT="im produktiven Einsatz dagegen soll die LocalBufferStage zum Einsatz kommen">
<node CREATED="1780151745703" ID="ID_1012098847" MODIFIED="1780151776312" TEXT="das impliziert auch Zugriff auf EngineBufferMetadata"/>
<node CREATED="1780151777809" ID="ID_1221701712" MODIFIED="1780151790310" TEXT="sowie das LocalSlice&lt;BufferMetadata&gt;"/>
<node CREATED="1780151790985" ID="ID_1920240436" MODIFIED="1780151804148" TEXT="d.h. letzteres ist eine im Thread schon vorhandene Instanz"/>
<node CREATED="1780151812751" ID="ID_44388280" MODIFIED="1780151841016" TEXT="wir verwenden lediglich eine andere Family-ID"/>
</node>
<node CREATED="1780151866703" ID="ID_1256214586" MODIFIED="1780151884297" TEXT="&#x27f9; weitere Aufgabe Family-ID generieren...">
<node CREATED="1780151914880" ID="ID_637880008" MODIFIED="1780151930538" TEXT="nicht klar ob die wirklich disjunkt sein mu&#xdf;"/>
<node CREATED="1780151948815" ID="ID_1862277956" MODIFIED="1780151964902" TEXT="denn eigentlich steckt im LocalTag die Speicher-Adresse der Connection-Impl"/>
<node CREATED="1780152111487" ID="ID_1991954161" MODIFIED="1780152165510" TEXT="und diese wird als 64bit-Zahl interpretiert und dann in den chained-Hash eingerechnet">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
siehe buffer-local-tag.hpp &#10230; ADL-friend hash_value(LocalTag)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780151931283" ID="ID_354341216" MODIFIED="1780151947457" TEXT="wenn jeder OutputSlot seine eigene Family-ID h&#xe4;tte, w&#xe4;ren wir auf der sicheren Seite"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1780152202274" ID="ID_947760326" MODIFIED="1780152372635" TEXT="allerdings: wir kummulieren auch mehr und mehr BufferTypen hier....">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1780152376643" ID="ID_1343911085" MODIFIED="1780152385542" TEXT="und zwar f&#xfc;r jede Connection per Channel"/>
<node CREATED="1780152388586" ID="ID_1657389174" MODIFIED="1780152406705" TEXT="die wird in einen Block in der ScopedCollection alloziert"/>
<node CREATED="1780152447760" ID="ID_373722952" MODIFIED="1780152467946" TEXT="es kann (tats&#xe4;chlich aber nicht) zu Aliasing kommen....">
<icon BUILTIN="info"/>
<node CREATED="1780152471606" ID="ID_1839376850" MODIFIED="1780152479409" TEXT="der Lifecycle verhindert das"/>
<node CREATED="1780152484381" ID="ID_855897238" MODIFIED="1780152529264" TEXT="solange es noch eine DataSink gibt...">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...bleibt der AllocState&lt;CON&gt; am Leben, und damit sind die Adressen / Hashes stabil
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780152532519" ID="ID_1359617045" MODIFIED="1780152539985" TEXT="danach sind die Typ-Eintr&#xe4;ge eigentlich obsolet"/>
<node CREATED="1780156671437" ID="ID_445565765" MODIFIED="1780156758581" TEXT="und Aliasing bliebe folgenlos">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Denn...
</p>
<ul>
<li>
der Hash stimmt nur, wenn die Speicher-Adressse und Buffer-Gr&#246;&#223;e exakt gleich ist
</li>
<li>
der konkrete Connection-Typ allerdings steckt in der Template-Instanz, d.h. im Code-Segment
</li>
<li>
deshalb funktioniert auch ein anderer Connection-Typ damit korrekt, solange die Buffer-Gr&#246;&#223;e pa&#223;t
</li>
</ul>
</body>
</html></richcontent>
<icon BUILTIN="idea"/>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1780156762817" ID="ID_816514752" MODIFIED="1780157247573" TEXT="ja ... die Ansammlung von Metadaten ist problematisch">
<linktarget COLOR="#cf0429" DESTINATION="ID_816514752" ENDARROW="Default" ENDINCLINATION="45;-685;" ID="Arrow_ID_1101777071" SOURCE="ID_1092563753" STARTARROW="None" STARTINCLINATION="533;32;"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1780157271150" ID="ID_117715815" MODIFIED="1780190717732" TEXT="Fazit: eine feste Family-ID gen&#xfc;gt (und ist besser)">
<icon BUILTIN="forward"/>
</node>
</node>
<node CREATED="1780157350708" ID="ID_1257598565" MODIFIED="1780157370191" TEXT="man k&#xf6;nnte das &#xbb;verteilte Setup&#xab; zum Default machen">
<icon BUILTIN="idea"/>
<node CREATED="1780157372408" ID="ID_177303366" MODIFIED="1780157389945" TEXT="denn ich erwarte nicht, da&#xdf; man h&#xe4;ufig einen OutputSlot erstellt f&#xfc;r Tests"/>
<node CREATED="1780157390775" ID="ID_893361688" MODIFIED="1780157401303" TEXT="daf&#xfc;r gibt es den DiagnosticOutputSlot..."/>
</node>
</node>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1780157415754" ID="ID_836082181" MODIFIED="1780190634455" TEXT="Art der Konfiguration">
<icon BUILTIN="yes"/>
<node CREATED="1780179973334" ID="ID_1785953051" MODIFIED="1780179977640" TEXT="M&#xf6;glichkeiten">
<node CREATED="1780179996698" ID="ID_1702570851" MODIFIED="1780180156917" TEXT="AllocState nimmt eine Setup-Policy (es gibt aber eine Spezialisierung f&#xfc;r CON)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das lie&#223;e sich per Concept realisieren: wenn der Template-Parameter eine Connection-Subclass ist, greift die Spezialisierung und generiert eine default-Setup-Policy, andernfalls mu&#223; der Template-Parameter selber die Policy sein, und diese hat dann eine embedded typedef Connection
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780180182368" ID="ID_214620505" MODIFIED="1780182935929" TEXT="AllocState nimmt einen zus&#xe4;tzlichen Template value parameter bool isTest = false">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...diese Variante h&#228;tte den Charme da&#223; am bestehenden Code fast nichts ge&#228;ndert werden mu&#223;, und man den Test-Schalter normalerweise gar nicht sieht
</p>
</body>
</html></richcontent>
<icon BUILTIN="forward"/>
</node>
<node CREATED="1780180323038" ID="ID_1427790811" MODIFIED="1780181012615" TEXT="AllocState bekommt ein 3. Konstruktur-Argument bool isTest">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...in diesem Fall m&#252;&#223;te auch OutputBufferProxy per Konstruktor-Parameter gesteuert werden (also dynamisch); weiterhin sehe ich als problematisch da&#223; der Konstruktor bereits einen relativ anspruchstvollen 2. Parameter nimmt
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780180798189" ID="ID_1572447367" MODIFIED="1780180918491" TEXT="OutputBufferStore::Setup wird per ADL-free-function gesteuert">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...die default-Implementierung macht nix, aber in speziellen F&#228;llen kann man f&#252;r einen bestimmten Connection-Typ in das ssetup eingreifen
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1780158092842" ID="ID_1892035013" MODIFIED="1780185053796" TEXT="Template-Flag erscheint naheliegend"/>
<node COLOR="#338800" CREATED="1780158114597" ID="ID_1787852906" MODIFIED="1780185343520" TEXT="die zieht sich dann aber nach oben">
<icon BUILTIN="button_ok"/>
<node CREATED="1780184998171" ID="ID_1740150679" MODIFIED="1780185165009" TEXT="AllocState bekommt dann ebenfalls so einen template-Parameter"/>
<node CREATED="1780185015612" ID="ID_1620894240" MODIFIED="1780185244577" TEXT="und dann ist es eigentlich nur f&#xfc;r Subklassen nutzbar">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...weil AllocState eine protected-Definition ist (und auch bleiben soll, um klar zu machen, da&#223; das Interna sind)
</p>
<p>
.....alle normalen Verwendungen sollten ja durch OutputSlot::allocate() gehen; dort kann ich aber sinnvollerweise keinen weiteren Template-Parameter mit Default unterbringen (weil der 2.Parameter, die Populator-Funktion, stets inferiert werden soll)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1780185056419" ID="ID_1696041175" MODIFIED="1780185122538" TEXT="kein Problem &#x27f6; ist auch nur ein seltener Spezialfall">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
aktuell haben wir nur den DiagnosticOutputSlot, sowie den OutputAllocState_test
</p>
<p>
...und ich erwarte nicht, da&#223; da noch viel dazukommt
</p>
</body>
</html></richcontent>
</node>
</node>
</node>
<node COLOR="#338800" CREATED="1780185348750" ID="ID_179622995" MODIFIED="1780190636425" TEXT="sollte dann auch noch die Populator-Notation vereinfachen">
<icon BUILTIN="button_ok"/>
<node CREATED="1780185384513" ID="ID_771620595" MODIFIED="1780185414149" TEXT="damit man nicht mehr mit dem ScopedCollection&lt;CON&gt;::ElementHolder hantieren mu&#xdf;"/>
<node CREATED="1780185369012" ID="ID_233099017" MODIFIED="1780185383776" TEXT="das hatte ich neulich schon generisch for lib::ScopedCollection eingef&#xfc;hrt"/>
<node CREATED="1780187139035" ID="ID_788155685" MODIFIED="1780187375604" TEXT="ist aber hier &#xfc;berraschend schwierig &#x2014; einfache Notation gew&#xfc;nscht">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Die vorgefertigten Populator-Builder in lib::ScopedCollection sind nested static functions, da sie implizit Bezug nehmen auf den Payload-Typ und den ElementHolder &#8212; das ist schon normalerweise eine Komplikation, die sich aber i.d.R. umgehen l&#228;&#223;t, indem man vorher im Nutz-Kontext eine Typedef einf&#252;hrt f&#252;r die lib::ScopedCollection&lt;Payload&gt;. Typisches Besipiel:
</p>
<div style="background-color: #eee0b5; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; padding-left: 2px">
<div style="color: #202020; background-color: #eee0b5; font-family: DejaVu Sans Mono; font-size: 9pt; white-space: pre">
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
<font color="#977b75">// Start a collection of workers....</font>
</p>
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
<font color="#4a1a65"><b>using</b></font><font color="#3a1f18">&#160;</font><font color="#8c505c"><b>Threads</b></font><font color="#3a1f18">&#160;</font><font color="#65533c">=</font><font color="#3a1f18">&#160;</font><font color="#635e96"><b>ScopedCollection</b></font><font color="#65533c">&lt;</font><font color="#635e96"><b>DummyWorkerThread</b></font><font color="#65533c">&lt;&gt;&gt;;</font>
</p>
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
<font color="#8c505c"><b>Threads</b></font><font color="#3a1f18">&#160;</font><font color="#814422">threads</font><font color="#11123a">{</font><font color="#dd1616"><i>MANY_THREADS</i></font><font color="#65533c">,</font><font color="#3a1f18">&#160; </font><font color="#8c505c"><b>Threads</b></font><font color="#65533c">::</font><font color="#61143c"><i>fill</i></font><font color="#11123a">()}</font><font color="#65533c">;</font>
</p>
<p style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0">
</p>
</div>
</div>
</body>
</html></richcontent>
</node>
<node CREATED="1780187395361" ID="ID_341802735" MODIFIED="1780187778548" TEXT="m&#xf6;gliche L&#xf6;sung: den wichtigsten Fall als Overload der allocate-Funktion">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Der wichtigste Fall ist sicherlich ScopedCollection&lt;CON&gt;::fill(ARGS...)
</p>
<p>
Einen solchen Overload k&#246;nnte man einf&#252;hren, wenn der andere Overload durch ein Concept gesch&#252;tzt w&#228;re
</p>
</body>
</html></richcontent>
<node CREATED="1780187800224" ID="ID_1450687362" MODIFIED="1780187826948" TEXT="Problem: dann mu&#xdf; ich die Dependency auf ScopedCollection hier explizit machen"/>
<node CREATED="1780187827880" ID="ID_1215350663" MODIFIED="1780187846167" TEXT="und das will ich nicht &#x2014; es ist ein Implementierungs-Detail"/>
<node CREATED="1780188273947" ID="ID_740333087" MODIFIED="1780190619991" TEXT="also anders herum &#x27f6; die Definition nach output-slot-connection.hpp verschieben">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...denn <i>dort</i>&#160;kann ich die Populator-Builder direkt verwenden; anstatt auf den &#187;Populator&#171; mit einem std::invocable-Concept abzustellen, k&#246;nnte ich stattdessen den Overload f&#252;r die direkte Konstruktion guarden
</p>
</body>
</html></richcontent>
</node>
</node>
<node COLOR="#435e98" CREATED="1780190641110" ID="ID_321395684" MODIFIED="1780190648726" TEXT="geht durch den Compiler....">
<font ITALIC="true" NAME="SansSerif" SIZE="12"/>
</node>
</node>
<node COLOR="#338800" CREATED="1780190654468" ID="ID_185120086" MODIFIED="1780190703838" TEXT="verifiziert(Debugger): OutputAllocState_test verwendet tats&#xe4;chlich SimpleBufferStateRegistry">
<icon BUILTIN="button_ok"/>
</node>
</node>
</node>
</node>
@ -146364,7 +146841,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776817873864" FOLDED="true" ID="ID_1964767554" MODIFIED="1778792259242" TEXT="Diskussion und Abw&#xe4;gung">
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1776817873864" FOLDED="true" ID="ID_1964767554" MODIFIED="1780191122011" TEXT="Diskussion und Abw&#xe4;gung">
<linktarget COLOR="#651733" DESTINATION="ID_1964767554" ENDARROW="Default" ENDINCLINATION="-51;-1908;" ID="Arrow_ID_1601176637" SOURCE="ID_471365898" STARTARROW="None" STARTINCLINATION="-1556;58;"/>
<node CREATED="1776817881283" ID="ID_1958629364" MODIFIED="1776817923320" TEXT="tats&#xe4;chlich liegen die Modelle gar nicht so weit auseinander....">
<richcontent TYPE="NOTE"><html>
@ -146409,9 +146886,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
</node>
</node>
<node COLOR="#5b280f" CREATED="1776818311073" ID="ID_52317148" MODIFIED="1776993715217" TEXT="Ich halte es f&#xfc;r gerechtfertigt, mein bestehendes Design weiterzuverfolgen">
<node COLOR="#5b280f" CREATED="1776818311073" FOLDED="true" ID="ID_52317148" MODIFIED="1780191066141" TEXT="Ich will mein bestehendes Design weiterverfolgen (STOP besser nicht!)">
<font NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="button_cancel"/>
<icon BUILTIN="yes"/>
<node COLOR="#5b280f" CREATED="1776993849979" FOLDED="true" ID="ID_553679429" MODIFIED="1777317428449" TEXT="was mu&#xdf; ich daf&#xfc;r tun....?">
<icon BUILTIN="button_cancel"/>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1776818387320" ID="ID_1007099106" MODIFIED="1777317376634" TEXT="BufferMetadata braucht ein Interface f&#xfc;r das Umh&#xe4;ngen von Typen">
@ -146869,6 +147347,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<node CREATED="1777074521660" ID="ID_1763982951" MODIFIED="1777074532534" TEXT="grunds&#xe4;tzlich: gehe von einer kleinen Anzahl an Eintr&#xe4;gen aus"/>
</node>
<node COLOR="#338800" CREATED="1777159795008" FOLDED="true" ID="ID_851031995" MODIFIED="1780099251457" TEXT="Heuristik zum Aufr&#xe4;umen schaffen">
<linktarget COLOR="#67a5cd" DESTINATION="ID_851031995" ENDARROW="Default" ENDINCLINATION="-325;-25;" ID="Arrow_ID_857205470" SOURCE="ID_9231521" STARTARROW="None" STARTINCLINATION="531;32;"/>
<icon BUILTIN="button_ok"/>
<node CREATED="1777160636295" ID="ID_1174478817" MODIFIED="1777160642510" TEXT="gew&#xfc;nschter Effekt">
<node CREATED="1777160710978" ID="ID_393248452" MODIFIED="1777160729106" TEXT="m&#xf6;glichst wenige und m&#xf6;glichst gut passende Buffer lokal halten"/>
@ -149129,6 +149608,30 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
<node BACKGROUND_COLOR="#d2beaf" COLOR="#5c4d6e" CREATED="1779806981481" ID="ID_339298449" MODIFIED="1779807068096" TEXT="Integration und Tests">
<icon BUILTIN="hourglass"/>
<node COLOR="#251b70" CREATED="1780191319570" ID="ID_947864507" MODIFIED="1780191578487" TEXT="Zwischenstand">
<font BOLD="true" NAME="SansSerif" SIZE="12"/>
<icon BUILTIN="forward"/>
<node BACKGROUND_COLOR="#c8c0b6" COLOR="#435e98" CREATED="1780191327746" ID="ID_804866125" MODIFIED="1780260464094" TEXT="Mai 26: habe nun eine &#xbb;production-grade&#xab;-Implementierung gebaut">
<linktarget COLOR="#666a8e" DESTINATION="ID_804866125" ENDARROW="Default" ENDINCLINATION="-736;0;" ID="Arrow_ID_831131977" SOURCE="ID_803703902" STARTARROW="None" STARTINCLINATION="-288;15;"/>
</node>
<node CREATED="1780191344440" ID="ID_243141002" MODIFIED="1780191553069" TEXT="verwende thread-local-Services + Async-Messaging">
<icon BUILTIN="info"/>
</node>
<node BACKGROUND_COLOR="#ccb59b" COLOR="#6e2a38" CREATED="1780191368251" ID="ID_1603680240" MODIFIED="1780191546353" TEXT="ziemlich komplexes Ding &#x2014; bin aber sehr zufrieden mit meiner Design-Arbeit">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Das war ein massives St&#252;ck Arbeit &#8212; hat auch <i>viel l&#228;nger gebraucht</i>&#160;als unrspr&#252;nglich geplant.
</p>
<p>
Daf&#252;r habe ich nun bereits einen Prototypen f&#252;r das Buffer-Management, das meinem Erfahrungs-Stand bzgl. performant/paralleller Systeme entspricht. Dieser Prototyp ist <i>sicherlich noch nicht ausgereift</i>&#160;und hat erhebliches Optimierungs-Potential. Zudem habe ich das gesamte Thema &#187;Allokation&#171; komplett &#252;bersprungen (und mache einfach Heap-Allokationen im EngineBufferManager)
</p>
</body>
</html></richcontent>
<font ITALIC="true" NAME="SansSerif" SIZE="14"/>
</node>
</node>
<node CREATED="1779811803748" ID="ID_1356647567" MODIFIED="1779811814407" TEXT="Tests">
<node COLOR="#1f5672" CREATED="1779811854629" ID="ID_200114754" MODIFIED="1780099481123" TEXT="BufferProviderLoad_test">
<arrowlink COLOR="#4587d6" DESTINATION="ID_475125993" ENDARROW="Default" ENDINCLINATION="-174;35;" ID="Arrow_ID_1000436933" STARTARROW="None" STARTINCLINATION="93;10;"/>
@ -149210,8 +149713,8 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</node>
<node CREATED="1778113564544" ID="ID_1131259858" MODIFIED="1778113686162" TEXT="Integration IO-Buffer">
<linktarget COLOR="#4359d9" DESTINATION="ID_1131259858" ENDARROW="Default" ENDINCLINATION="-1448;-166;" ID="Arrow_ID_863939341" SOURCE="ID_688748631" STARTARROW="None" STARTINCLINATION="-1197;90;"/>
<node CREATED="1778116471691" ID="ID_1679522795" MODIFIED="1778116528777" TEXT="Struktur der Jobs">
<linktarget COLOR="#4b5174" DESTINATION="ID_1679522795" ENDARROW="Default" ENDINCLINATION="28;-1464;" ID="Arrow_ID_934032093" SOURCE="ID_847440044" STARTARROW="None" STARTINCLINATION="-552;47;"/>
<node CREATED="1778116471691" ID="ID_1679522795" MODIFIED="1780241775090" TEXT="Struktur der Jobs">
<linktarget COLOR="#4b5174" DESTINATION="ID_1679522795" ENDARROW="Default" ENDINCLINATION="-100;-627;" ID="Arrow_ID_934032093" SOURCE="ID_847440044" STARTARROW="None" STARTINCLINATION="-552;47;"/>
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1778116557314" ID="ID_1411146534" MODIFIED="1778116580325" TEXT="der IO-Job ist gar nicht mit einer (normalen) Node verbunden...?">
<icon BUILTIN="help"/>
<node CREATED="1778116600409" ID="ID_970184894" MODIFIED="1779807245515" TEXT="oder vielleicht doch?">
@ -149231,7 +149734,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</ul>
</body>
</html></richcontent>
<arrowlink COLOR="#850b20" DESTINATION="ID_1426869397" ENDARROW="Default" ENDINCLINATION="59;906;" ID="Arrow_ID_881098297" STARTARROW="None" STARTINCLINATION="-845;-127;"/>
<arrowlink COLOR="#850b20" DESTINATION="ID_1426869397" ENDARROW="Default" ENDINCLINATION="6;603;" ID="Arrow_ID_881098297" STARTARROW="None" STARTINCLINATION="-845;-127;"/>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1778116949044" ID="ID_1923307878" MODIFIED="1778117221275" TEXT="der nachgelagerte Render-Job mu&#xdf; irgendwie den Quell-Buffer schon bekommen">
@ -149814,6 +150317,17 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
</body>
</html></richcontent>
<arrowlink COLOR="#76516c" DESTINATION="ID_1415408255" ENDARROW="Default" ENDINCLINATION="779;39;" ID="Arrow_ID_1408352744" STARTARROW="None" STARTINCLINATION="468;17;"/>
<node CREATED="1780148019289" HGAP="41" ID="ID_1395244829" MODIFIED="1780190816404" TEXT="modifiziertes Ziel: in das System der Metadaten-Stores integrieren" VSHIFT="9">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
mit dem Aufbau der production-grade-Implementierung des BufferProviders mu&#223;te ich auch das Problem l&#246;sen, wie die einzelnen Threads auf die Metadaten zugreifen: es gibt nun EngineMetadata, sowie in jedem Thread ein LocalSllice&lt;BufferMetadata&gt;.....
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#1e4d87" DESTINATION="ID_509761355" ENDARROW="Default" ENDINCLINATION="-54;837;" ID="Arrow_ID_569900076" STARTARROW="None" STARTINCLINATION="96;-1313;"/>
</node>
</node>
<node BACKGROUND_COLOR="#e0ceaa" COLOR="#690f14" CREATED="1773704083017" FOLDED="true" ID="ID_446456909" MODIFIED="1774223593951" TEXT="Anordnung und Zugriffe sind problematisch in der bestehenden Architektur">
<icon BUILTIN="broken-line"/>
@ -150301,7 +150815,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<head/>
<body>
<p>
Concepts sind ein relativ komplexes Gebilde, und sie haben eine spezielle Notierung, die in der Form nur in C++ gegeben ist. Nur ein Bruchteil der C++ - Entwickler wir mit Konzepten vertraut werden (auf lange Zeit). Zudem hinterl&#228;&#223;t ein Konzept <i>in der Implementierung keine Spuren. </i>Man k&#246;nnte sich da zwar etwas einfallen lassen, aber das w&#228;re dann noch mehr ein Spezial-Konstrukt. Das ist etwas, was sich erst noch herausbilden mu&#223; (auch die Tool-Unterst&#252;tzung ist ein Aspekt).
Concepts sind ein relativ komplexes Gebilde, und sie haben eine spezielle Notierung, die in der Form nur in C++ gegeben ist. Nur ein Bruchteil der C++ - Entwickler wird mit Konzepten vertraut werden (auf lange Zeit). Zudem hinterl&#228;&#223;t ein Konzept <i>in der Implementierung keine Spuren. </i>Man k&#246;nnte sich da zwar etwas einfallen lassen, aber das w&#228;re dann noch mehr ein Spezial-Konstrukt. Das ist etwas, was sich erst noch herausbilden mu&#223; (auch die Tool-Unterst&#252;tzung ist ein Aspekt).
</p>
<p>
Demgegen&#252;ber ist ein klassisches OO-Interface ein seit 30 Jahren universell bekanntes und weithin unterst&#252;tztes Schema, das in den allermeisten Sprachen in irgend einer Form eingesetzt wird (selbst wenn die Sprachen sonst nicht OO sind). Wenn ich einem durchschnittlichen Entwickler heute sage: &#8222;Du mu&#223;t das Interface Connection implementieren&#8220;, dann setzt der sich einfach hin und klopft das runter.
@ -151233,7 +151747,7 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<arrowlink COLOR="#ff1125" DESTINATION="ID_1351243761" ENDARROW="Default" ENDINCLINATION="669;80;" ID="Arrow_ID_1409482268" STARTARROW="None" STARTINCLINATION="788;42;"/>
<arrowlink COLOR="#ff1125" DESTINATION="ID_774940151" ENDARROW="Default" ENDINCLINATION="681;34;" ID="Arrow_ID_1530530196" STARTARROW="None" STARTINCLINATION="1318;69;"/>
</node>
<node CREATED="1775917228753" ID="ID_926670050" MODIFIED="1775917392650" TEXT="OutputSlot wurd Fr&#xfc;hjahr26 grundlegend &#xfc;berarbeitet">
<node CREATED="1775917228753" ID="ID_926670050" MODIFIED="1780147358885" TEXT="OutputSlot wurde Fr&#xfc;hjahr26 grundlegend &#xfc;berarbeitet">
<arrowlink COLOR="#498ad6" DESTINATION="ID_1023733837" ENDARROW="Default" ENDINCLINATION="-757;-817;" ID="Arrow_ID_534861876" STARTARROW="None" STARTINCLINATION="688;37;"/>
</node>
<node CREATED="1773941728897" ID="ID_1047888380" MODIFIED="1773941769804" TEXT="sollte im Data-Sink eine Stream-Type-ID unterbringen (k&#xf6;nnen wollen)">
@ -151245,6 +151759,10 @@ StM_bind(Builder&lt;R1&gt; b1, Extension&lt;R1,R2&gt; extension)
<arrowlink COLOR="#2129bf" DESTINATION="ID_1782289710" ENDARROW="Default" ENDINCLINATION="-514;144;" ID="Arrow_ID_1760765205" STARTARROW="None" STARTINCLINATION="470;-797;"/>
<icon BUILTIN="idea"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1721238814245" ID="ID_503976809" MODIFIED="1780155133920" TEXT="Gefahr: Output-Connection mu&#xdf; threadsafe sein">
<linktarget COLOR="#fe512a" DESTINATION="ID_503976809" ENDARROW="Default" ENDINCLINATION="1101;-48;" ID="Arrow_ID_744367367" SOURCE="ID_506159225" STARTARROW="None" STARTINCLINATION="-943;53;"/>
<icon BUILTIN="clanbomber"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1681347244544" ID="ID_444443795" MODIFIED="1681347486789" TEXT="Basis: Operational Control">
@ -179885,7 +180403,7 @@ std::cout &lt;&lt; tmpl.render({&quot;what&quot;, &quot;World&quot;}) &lt;&lt; s
</node>
</node>
<node CREATED="1749432400380" ID="ID_1422603149" MODIFIED="1749432404143" TEXT="Neuerungen">
<node CREATED="1749432405584" ID="ID_1749311235" MODIFIED="1751556699132" TEXT="Spaceship und comparisons">
<node CREATED="1749432405584" FOLDED="true" ID="ID_1749311235" MODIFIED="1751556699132" TEXT="Spaceship und comparisons">
<node CREATED="1751553920416" ID="ID_1478329508" MODIFIED="1751553933142" TEXT="zwei Basis-Operatoren">
<node CREATED="1751553934321" ID="ID_1726777708" MODIFIED="1751553952618" TEXT="== : equality"/>
<node CREATED="1751553936994" ID="ID_1994276563" MODIFIED="1751553948379" TEXT="&lt;=&gt; : three-way-comparison">
@ -181857,6 +182375,9 @@ unsigned int ThreadIdAsInt = *static_cast&lt;unsigned int*&gt;(static_cast&lt;vo
</p>
</body>
</html></richcontent>
<node CREATED="1780257465402" ID="ID_42443800" MODIFIED="1780257477041" TEXT="(sollte 96 dpi sein)">
<font NAME="SansSerif" SIZE="11"/>
</node>
</node>
<node CREATED="1773531239072" ID="ID_636064275" MODIFIED="1773531254153" TEXT="Padding auf der Seite einbauen"/>
<node CREATED="1773531255165" ID="ID_1102039599" MODIFIED="1773531266582" TEXT="Seitenhintergrund: Wei&#xdf;es Rechteck dahinter legen"/>