BufferProvider: consider to disentangle diagnostics and default implementation
The implementation code for `DiagnosticOutputProvider` and `TrackingHeapBlockProvider` look very confusing and tangled. It seems, instrumentation for tests got mixed up with the effort to provide a simplistic prototype implementation. What we need foremost here is the latter; most tests that import the DiagnosticOutputProvider do not even use any instrumentation....
This commit is contained in:
parent
0f12b19148
commit
256c446705
10 changed files with 48 additions and 47 deletions
|
|
@ -24,7 +24,7 @@
|
|||
#include "lib/meta/function.hpp"
|
||||
|
||||
#include "steam/engine/diagnostic-buffer-provider.hpp"
|
||||
#include "steam/engine/tracking-heap-block-provider.hpp"
|
||||
#include "steam/engine/heap-mem-provider.hpp"
|
||||
|
||||
|
||||
namespace steam {
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
TrackingHeapBlockProvider - plain heap allocating BufferProvider implementation for tests
|
||||
HeapMemProvider - plain heap allocating BufferProvider implementation for tests
|
||||
|
||||
Copyright (C)
|
||||
2011, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
@ -12,7 +12,7 @@
|
|||
* *****************************************************************/
|
||||
|
||||
|
||||
/** @file tracking-heap-block-provider.cpp
|
||||
/** @file heap-mem-provider.cpp
|
||||
** Implementation details of a mock engine::BufferProvider for unit testing
|
||||
*/
|
||||
|
||||
|
|
@ -22,7 +22,7 @@
|
|||
#include "lib/scoped-ptrvect.hpp"
|
||||
#include "lib/util-foreach.hpp"
|
||||
|
||||
#include "steam/engine/tracking-heap-block-provider.hpp"
|
||||
#include "steam/engine/heap-mem-provider.hpp"
|
||||
|
||||
#include <algorithm>
|
||||
#include <vector>
|
||||
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
TRACKING-HEAP-BLOCK-PROVIDER.hpp - plain heap allocating BufferProvider implementation for tests
|
||||
HEAP-MEM-PROVIDER.hpp - plain heap allocating BufferProvider implementation for tests
|
||||
|
||||
Copyright (C)
|
||||
2011, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
@ -11,27 +11,27 @@
|
|||
|
||||
*/
|
||||
|
||||
/** @file tracking-heap-block-provider.hpp
|
||||
/** @file heap-mem-provider.hpp
|
||||
** Dummy implementation of the BufferProvider interface to support writing unit tests.
|
||||
** This BufferProvider is especially straight forward and brain dead: it just claims
|
||||
** more and more heap blocks and never releases any memory dynamically. This allows
|
||||
** to investigate additional tracking status flags for each allocated block after
|
||||
** the fact.
|
||||
** This BufferProvider implementation is notably straight forward and silly: it just
|
||||
** claims more and more heap blocks and never releases any memory dynamically. This allows
|
||||
** to investigate additional tracking status flags for each allocated block after the fact.
|
||||
**
|
||||
** The allocated buffers are numbered with a simple ascending sequence of integers,
|
||||
** used as LocalTag (see BufferMetadata). Clients can just request a Buffer with the
|
||||
** given number, causing that block to be allocated. There is a "backdoor", allowing
|
||||
** to access any allocated block, even if it is considered "released" by the terms
|
||||
** of the usual lifecycle. Only when the provider object itself gets destroyed,
|
||||
** all allocated blocks will be discarded.
|
||||
** @todo 1/2026 for sake of implementation clarity, the following instrumentation functionality
|
||||
** must be relocated into the DiagnosticOutputProvider: Allocated buffers are numbered
|
||||
** with a simple ascending sequence of integers, used as LocalTag (see BufferMetadata).
|
||||
** Clients can request a Buffer with the given number, causing that block to be allocated.
|
||||
** There is a "backdoor", allowing to access any allocated block, even if it is considered
|
||||
** "released" by the terms of the usual lifecycle. Only when the provider object itself
|
||||
** gets destroyed, all allocated blocks will be discarded.
|
||||
**
|
||||
** @see DiagnosticOutputSlot
|
||||
** @see DiagnosticBufferProvider
|
||||
** @see buffer-provider-protocol-test.cpp
|
||||
*/
|
||||
|
||||
#ifndef STEAM_ENGINE_TRACKING_HEAP_BLOCK_PROVIDER_H
|
||||
#define STEAM_ENGINE_TRACKING_HEAP_BLOCK_PROVIDER_H
|
||||
#ifndef STEAM_ENGINE_HEAP_MEM_PROVIDER_H
|
||||
#define STEAM_ENGINE_HEAP_MEM_PROVIDER_H
|
||||
|
||||
|
||||
#include "lib/error.hpp"
|
||||
|
|
@ -178,4 +178,4 @@ namespace engine {
|
|||
|
||||
|
||||
}} // namespace steam::engine
|
||||
#endif
|
||||
#endif /*STEAM_ENGINE_HEAP_MEM_PROVIDER_H*/
|
||||
|
|
@ -25,7 +25,7 @@
|
|||
#include "steam/engine/render-environment.hpp"
|
||||
#include "steam/engine/engine-facilities.hpp"
|
||||
#include "steam/engine/buffer-provider.hpp"
|
||||
#include "steam/engine/tracking-heap-block-provider.hpp"
|
||||
#include "steam/engine/heap-mem-provider.hpp"
|
||||
|
||||
|
||||
namespace steam {
|
||||
|
|
@ -46,12 +46,12 @@ namespace engine{
|
|||
/* ===== Render Environment Implementation ===== */
|
||||
|
||||
|
||||
/////////////////////////////////////////////////////////////TODO
|
||||
///////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1409 : actually build that! right now (1/2026) it is a conceptual placeholder
|
||||
/// The real Render Engine needs a well defined life cycle;
|
||||
/// services must be booted and shut down.
|
||||
/// Notably a dedicated serivce-like subclass of EngineCtx
|
||||
/// must be created here and installed for lib::Depend<EngineCtx>
|
||||
///
|
||||
///
|
||||
|
||||
|
||||
/* ===== Access to Render Engine Facilities ===== */
|
||||
|
|
|
|||
|
|
@ -13,15 +13,14 @@
|
|||
|
||||
|
||||
/** @file render-environment.hpp
|
||||
** The active core within a CalcStream, causing the render mechanism to re-trigger repeatedly.
|
||||
** Rendering is seen as an open-ended, ongoing process, and thus the management and planning
|
||||
** of the render process itself is performed chunk wise and embedded into the other rendering
|
||||
** calculations. The _"rendering-as-it-is-planned-right-now"_ can be represented as a closure
|
||||
** to the jobs, which perform and update this plan on the go. And in fact, the head of the
|
||||
** planning process, the CalcStream, maintains this closure instance, as parametrised
|
||||
** with the appropriate configuration for the specific playback/render process underway.
|
||||
** Enclosed into this instance lives the actual job planning pipeline, connected at the
|
||||
** rear to the dispatcher and thus to the fixture and the low-level model
|
||||
** A configuration context for processing within the Render Engine.
|
||||
** This context can be accessed from within the ongoing render processes to query
|
||||
** strategy settings; actually, all the global support facilities within the Render Engine
|
||||
** are attached here. Thus it might also be used to control the lifecycle (2026 not clear yet)
|
||||
** @todo 2026 the concept is quite old, but I have reestablished it now to use it as an anchor.
|
||||
** it is not clear yet if there will be several sub environments for different playback
|
||||
** configurations; effectively, this is a conceptual placeholder now and needs to be
|
||||
** put into actual use to see where this leads us to.... ////////////////////////////////////////////TICKET #1409
|
||||
**
|
||||
** @todo 4/2023 »Playback Vertical Slice« -- effort towards first integration of render process ////////////TICKET #1221
|
||||
*/
|
||||
|
|
@ -37,7 +36,7 @@
|
|||
|
||||
|
||||
namespace steam {
|
||||
namespace engine {
|
||||
namespace engine{
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -16,6 +16,8 @@
|
|||
** Implementation functionality to bridge between engine::PlayService and engine::EngineService.
|
||||
** The former allows to start playback (or rendering) as a high-level activity, while the latter
|
||||
** can manage and perform [calculation streams](\ref CalcStream)
|
||||
**
|
||||
** @todo 2026 : the concept seems valid, but needs to be refined and integrated with play processing ///////TICKET #868
|
||||
*/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -7,17 +7,17 @@ return: 0
|
|||
END
|
||||
|
||||
|
||||
TEST "Test support: dummy buffer provider" TrackingHeapBlockProvider_test <<END
|
||||
TEST "Test support: buffer provider" DiagnosticBufferProvider_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
||||
TEST "Buffer provider diagnostics" BufferProviderProtocol_test <<END
|
||||
TEST "Buffer provider protocol" BufferProviderProtocol_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
||||
TEST "Bbuffer metadata type keys" BufferMetadataKey_test <<END
|
||||
TEST "Buffer metadata type keys" BufferMetadataKey_test <<END
|
||||
return: 0
|
||||
END
|
||||
|
||||
|
|
|
|||
|
|
@ -232,7 +232,7 @@ namespace test{
|
|||
mockDumm->response = 11;
|
||||
CHECK (11 == dumm().probe() ); // NOTE: now returning the response changed on the mock instance
|
||||
|
||||
CHECK (!mockDummy3); // the second mock is still in not yet created state...
|
||||
CHECK (!mockDummy3); // the second mock is still in 'not yet created' state...
|
||||
CHECK ((1+5+7+3) == checksum );
|
||||
CHECK (-1 == depp().probe() );
|
||||
CHECK ((1+5+7+3+3) == checksum ); // ...and now we got a second mock instance!
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
/*
|
||||
TrackingHeapBlockProvider(Test) - verify a support facility for diagnostic/test purposes
|
||||
DiagnosticBufferProvider(Test) - verify a support facility for diagnostic/test purposes
|
||||
|
||||
Copyright (C)
|
||||
2011, Hermann Vosseler <Ichthyostega@web.de>
|
||||
|
|
@ -12,13 +12,13 @@
|
|||
* *****************************************************************/
|
||||
|
||||
/** @file tracking-heap-block-provider-test.cpp
|
||||
** unit test \ref TrackingHeapBlockProvider_test
|
||||
** unit test \ref DiagnosticBufferProvider_test
|
||||
*/
|
||||
|
||||
|
||||
#include "lib/error.hpp"
|
||||
#include "lib/test/run.hpp"
|
||||
#include "steam/engine/tracking-heap-block-provider.hpp"
|
||||
#include "steam/engine/heap-mem-provider.hpp"
|
||||
#include "steam/engine/buffhandle-attach.hpp"
|
||||
#include "steam/engine/testframe.hpp"
|
||||
|
||||
|
|
@ -59,13 +59,13 @@ namespace test {
|
|||
|
||||
|
||||
/******************************************************************//**
|
||||
* @test verify a test support facility, used to write mock components
|
||||
* to test the lumiera engine. The TrackingHeapBlockProvider is a
|
||||
* braindead implementation of the BufferProvider interface: it just
|
||||
* claims new heap blocks and never de-allocates them, allowing other
|
||||
* test and mock objects to verify allocated buffers after the fact.
|
||||
* @test verify support to write mock components for buffer management.
|
||||
* - HeapMemProvider is a „braindead“ implementation of the BufferProvider
|
||||
* interface: it just claims new heap blocks and never de-allocates them.
|
||||
* - adding a layer of instrumentation, the DiagnosticBufferProvider allows
|
||||
* to count and verify allocated buffers and their content after the fact.
|
||||
*/
|
||||
class TrackingHeapBlockProvider_test : public Test
|
||||
class DiagnosticBufferProvider_test : public Test
|
||||
{
|
||||
virtual void
|
||||
run (Arg)
|
||||
|
|
@ -210,7 +210,7 @@ namespace test {
|
|||
|
||||
|
||||
/** Register this test class... */
|
||||
LAUNCHER (TrackingHeapBlockProvider_test, "unit player");
|
||||
LAUNCHER (DiagnosticBufferProvider_test, "unit player");
|
||||
|
||||
|
||||
|
||||
|
|
@ -29,7 +29,7 @@
|
|||
#include "steam/play/output-slot-connection.hpp"
|
||||
#include "steam/asset/meta/time-grid.hpp"
|
||||
#include "steam/engine/buffhandle.hpp"
|
||||
#include "steam/engine/tracking-heap-block-provider.hpp"
|
||||
#include "steam/engine/heap-mem-provider.hpp"
|
||||
#include "lib/time/timevalue.hpp"
|
||||
#include "lib/scoped-ptrvect.hpp"
|
||||
#include "lib/iter-source.hpp"
|
||||
|
|
|
|||
Loading…
Reference in a new issue