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

Dispatcher: rename in accordance to the layer

Browse source 
so now we've got a "SteamDispatcher" ... cute ;-)
This commit is contained in:
Fischlurch 2018-11-23 21:29:54 +01:00
parent 2ea89fcb54
commit 7b7ec310b3
29 changed files with 116 additions and 116 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/technical/stage/GuiConnect.txt
View file

@ -56,7 +56,7 @@ Anatomy of the Steam/Stage interface
which can be considered __ ``the'' public session interface.__
Both these primary interfaces operate *message based.* As immediate consequence, these interfaces are comparatively
narrow, and interactions can easily be serialised, enqueued and dispatched. On the Steam-Layer side, the `ProcDispatcher`
narrow, and interactions can easily be serialised, enqueued and dispatched. On the Steam-Layer side, the `SteamDispatcher`
coordinates command execution and the _Builder run_ to derive the consequences of those session command invocations.
And within the UI, the GTK-Event loop runs likewise single threaded, and the Notification facade automatically
dispatches any invocation into the UI thread.

4
src/include/session-command-facade.h
View file

@ -35,11 +35,11 @@
** Steam-Layer implementation. The service implementation backing this
** facade indeed retrieves the corresponding steam::control::Command
** handles to perform the binding operation and hands them over
** to the ProcDispatcher for invocation.
** to the SteamDispatcher for invocation.
**
** @see command.hpp
** @see session-command-service.hpp implementation
** @see steam::control::ProcDispatcher
** @see steam::control::SteamDispatcher
** @see stage::ctrl::CoreService
*/

2
src/stage/ctrl/core-service.hpp
View file

@ -71,7 +71,7 @@
** messages, which can not be handled in a generic way on the Nexus:
** - *act* handles command invocation within the Session core, and
** is treated by [forwarding](\ref command-handler.hpp) it over the
** SessionCommand facade to the [Steam-Dispatcher](\ref proc-dispatcher.hpp)
** SessionCommand facade to the [Steam-Dispatcher](\ref steam-dispatcher.hpp)
** - *note* observes and captures presentation state note messages, which
** are to be handled by a central presentation state manager (TODO 1/17).
**

2
src/stage/ui-bus.hpp
View file

@ -71,7 +71,7 @@
** ["opened"](\ref steam::control::SessionCommand::cycle(Symbol,string)) command instance ID.
** - the payload is a Record<GenNode> holding the actual command arguments
** - on reception, an _instance_ (anonymous clone copy) of the command is created, bound
** with the arguments and handed over to the ProcDispatcher to be enqueued for execution.
** with the arguments and handed over to the SteamDispatcher to be enqueued for execution.
** - *note*: send a [GenNode] representing the _state mark;_
** some (abstracted) presentation state manager is expected to listen to these messages,
** possibly recording state to be restored later. The contents of the _state mark_ message

4
src/steam/control/command-closure.hpp
View file

@ -22,7 +22,7 @@
/** @file command-closure.hpp
** A closure enabling self-contained execution of commands within the ProcDispatcher.
** A closure enabling self-contained execution of commands within the SteamDispatcher.
** After defining a steam-layer command, at some point the function arguments
** of the contained operation are "closed" by storing concrete argument values.
** These values will be fed later on to the operation when the command is invoked.
@ -57,7 +57,7 @@
** a clone copy of the argument (holder) without disclosing the actual types involved.
**
** @see Command
** @see ProcDispatcher
** @see SteamDispatcher
** @see command-storage-holder.hpp
** @see command-op-closure.hpp
**

4
src/steam/control/command-def.hpp
View file

@ -43,7 +43,7 @@
** @see Command
** @see Mutation
** @see CommandClosure
** @see ProcDispatcher
** @see SteamDispatcher
** @see CommandBasic_test simple usage example
**
*/
@ -264,7 +264,7 @@ namespace control {
* The basic idea is for the user to create a disposable instance of this definition helper,
* only for calling a chain of definition functions, which internally build the actual Command object.
* Finally, the created Command object will be stored into a registry or handed over to the
* ProcDispatcher. To give an example:
* SteamDispatcher. To give an example:
* \code
* CommandDefinition ("test.command1")
* .operation (command1::operate) // provide the function to be executed as command

4
src/steam/control/command-dispatch.hpp
View file

@ -22,9 +22,9 @@
/** @file command-dispatch.hpp
** Interface to abstract the ProcDispatcher's ability to handle command messages.
** Interface to abstract the SteamDispatcher's ability to handle command messages.
**
** @see proc-dispatcher.hpp
** @see steam-dispatcher.hpp
** @see session-command-service.hpp
** @see DispatcherLoop
**

2
src/steam/control/command-impl.hpp
View file

@ -33,7 +33,7 @@
** //TODO
**
** @see Command
** @see ProcDispatcher
** @see SteamDispatcher
**
*/

6
src/steam/control/command-instance-manager.hpp
View file

@ -35,11 +35,11 @@
** and provides dedicated instance IDs, which can be stored in the UI and later used to retrieve
** those instances for invocation. These IDs are created by decorating a base command ID, allowing
** for several competing invocations to exist at the same time. When finally a given invocation is
** about to happen, a corresponding registration handle is transfered to the ProcDispatcher, where
** about to happen, a corresponding registration handle is transfered to the SteamDispatcher, where
** it is enqueued for execution.
** \par lifecycle
** There CommandInstanceManager is maintained by the SessionCommandService, which in turn is
** installed and removed by the implementation within ProcDispatcher. Its lifecycle is thus tied
** installed and removed by the implementation within SteamDispatcher. Its lifecycle is thus tied
** to the opening / closing of the Steam-Layer interface, as dictated by the Session lifecycle.
** When the current session is closed, all command instances "underway" will thus be discarded.
**
@ -89,7 +89,7 @@ namespace control {
* (i.e. there is no registration of a command under that instanceID in the global CommandRegistry).
* When done with the parametrisation, by calling #dispatch, this anonymous instance will be handed
* over to the [Dispatcher](\ref CommandDispatch) (installed on construction). Typically, this will in fact
* be the steam::control::ProcDispatcher, which runs in a dedicated thread ("session loop thread") and
* be the steam::control::SteamDispatcher, which runs in a dedicated thread ("session loop thread") and
* maintains a queue of commands to be dispatched towards the current session. Since Command is a smart
* handle, the enqueued instance will stay alive until execution and then go out of scope. But, after
* #dispatch, it is no longer accessible from the CommandInstanceManger, and while it is still waiting

2
src/steam/control/command-mutation.hpp
View file

@ -35,7 +35,7 @@
**
**
** @see Command
** @see ProcDispatcher
** @see SteamDispatcher
** @see MementoTie binding memento state
**
*/

6
src/steam/control/command-queue.hpp
View file

@ -1,5 +1,5 @@
/*
COMMAND-QUEUE.hpp - organise ordering of commands within ProcDispatcher
COMMAND-QUEUE.hpp - organise ordering of commands within SteamDispatcher
Copyright (C) Lumiera.org
2016, Hermann Vosseler <Ichthyostega@web.de>
@ -22,7 +22,7 @@
/** @file command-queue.hpp
** Implementation building block of ProcDispatcher to organise commands.
** Implementation building block of SteamDispatcher to organise commands.
** This is the actual implementation of the command queue to allow for
** strictly sequential dispatch of commands to work on the session.
**
@ -30,7 +30,7 @@
** some further management functions like purging of expired commands
**
** @see CommandQueue_test
** @see proc-dispatcher.hpp
** @see steam-dispatcher.hpp
** @see session-command-service.hpp
** @see DispatcherLoop
** @see Looper

2
src/steam/control/command-registry.hpp
View file

@ -49,7 +49,7 @@
** until de-registered explicitly, or until application shutdown.
**
** @see Command
** @see ProcDispatcher
** @see SteamDispatcher
**
*/

4
src/steam/control/command.hpp
View file

@ -58,7 +58,7 @@
** @see command-use1-test.cpp
** @see command-use2-test.cpp
** @see command-use3-test.cpp
** @see ProcDispatcher
** @see SteamDispatcher
** @see Session
**
*/
@ -112,7 +112,7 @@ namespace control {
* a CommandDef somewhere to specify the actual operation and to define, how the
* effect of the command can be undone. Moreover, the command's definition
* refers to a HandlingPattern, which describes how the command is actually
* to be executed (the default is scheduling it within the ProcDispatcher)
* to be executed (the default is scheduling it within the SteamDispatcher)
*
* Client code usually just
* - creates a command instance by referring to a command ID

6
src/steam/control/handling-pattern.hpp
View file

@ -32,9 +32,9 @@
** invoke the CommandImpl API directly.
**
** @todo it is not clear what's the difference between "throw" and "no-throw" pattern
** @todo any integration with the (yet undefined as of 9/09) ProcDispatcher is missing.
** @todo any integration with the (yet undefined as of 9/09) SteamDispatcher is missing.
**
** @see ProcDispatcher
** @see SteamDispatcher
** @see Session
**
*/
@ -90,7 +90,7 @@ namespace control {
* Interface: Operation Skeleton how to invoke or undo a command.
* Concrete implementations may be retrieved by ID; they range
* from just invoking the command operations straight forward
* to dispatching with the ProcDispatcher or running the command
* to dispatching with the SteamDispatcher or running the command
* asynchronously in a background thread.
*/
class HandlingPattern

2
src/steam/control/handling-patterns.hpp
View file

@ -32,7 +32,7 @@
** the sequence within the enum HandlingPattern::ID; all of this
** is done hard wired and without any dynamic configuration.
**
** @see ProcDispatcher
** @see SteamDispatcher
** @see Session
**
*/

8
src/steam/control/looper.hpp
View file

@ -22,12 +22,12 @@
/** @file looper.hpp
** Implementation building block of ProcDispatcher to control waiting and timing.
** Implementation building block of SteamDispatcher to control waiting and timing.
** This helper encapsulates the loop control logic to separate it from actual
** implementation of timing and waiting (per pthread condition variables).
** It exposes a combined condition (to be used for waiting) plus any further
** state predicates necessary to manage the state transitions regarding the
** ProcDispatcher implementation:
** SteamDispatcher implementation:
** - detect working state, based on a closure to detect an non empty CommandQueue
** - handle the disabling and shutdown of the dispatching task
** - detect an idle state to allow the DispatcherLoop to go to sleep
@ -38,7 +38,7 @@
** used as a synchronisation point to halt the loop.
**
** @see DispatcherLooper_test
** @see proc-dispatcher.hpp
** @see steam-dispatcher.hpp
** @see DispatcherLoop
** @see CommandQueue
**
@ -228,7 +228,7 @@ namespace control {
/** @internal establish the typical timeout for idle sleep.
* When the ProcDispatcher has no work to do, it needs to wake up regularly
* When the SteamDispatcher has no work to do, it needs to wake up regularly
* for a checkpoint, to determine if the Builder needs to be triggered or
* the shutdown-flag be checked. So the period established here defines
* some kind of minimal reaction especially for the builder, so to ensure

2
src/steam/control/session-command-service.cpp
View file

@ -240,7 +240,7 @@ namespace control {
/** @remark actual instance created from within ProcDispatcher */
/** @remark actual instance created from within SteamDispatcher */
SessionCommandService::SessionCommandService (CommandDispatch& dispatcherLoopInterface)
: dispatcher_{dispatcherLoopInterface}
, instanceManager_{dispatcher_}

2
src/steam/control/session-command-service.hpp
View file

@ -68,7 +68,7 @@ namespace control {
* proxy within the application core to route calls through this interface.
*
* This service is backed by implementation facilities embedded within
* the ProcDispatcher, exposed through the CommandDispatch interface.
* the SteamDispatcher, exposed through the CommandDispatch interface.
* Additionally, it operates a CommandInstanceManager to allow the
* creation of local instances "opened" for argument binding.
* In fact, this is the standard "command cycle" and the

50
src/steam/control/proc-dispatcher.cpp → src/steam/control/steam-dispatcher.cpp
View file

@ -1,5 +1,5 @@
/*
ProcDispatcher - Steam-Layer command dispatch and execution
SteamDispatcher - Steam-Layer command dispatch and execution
Copyright (C) Lumiera.org
2008, Hermann Vosseler <Ichthyostega@web.de>
@ -21,15 +21,15 @@
* *****************************************************/
/** @file proc-dispatcher.cpp
/** @file steam-dispatcher.cpp
** Implementation details of running commands and the builder.
** The ProcDispatcher is at the heart of the session subsystem and implements a
** The SteamDispatcher is at the heart of the session subsystem and implements a
** (single) session thread to perform commands and trigger builder runs. New commands
** can be enqueued with a dedicated CommandQueue, while the details of operation control
** logic are encapsulated in a [logic component](\ref Looper).
**
** # Operational Semantics
** We need to distinguish between the ProcDispatcher itself, which is a static (singleton) service,
** We need to distinguish between the SteamDispatcher itself, which is a static (singleton) service,
** and the »Session Subsystem« plus the _Session proper._ The subsystem has an application-global lifecycle,
** while the Session itself is a data structure and can be closed, opened or re-loaded. There is a singular
** transactional access point to the Session datastructure, which can be switched to new session contents.
@ -62,7 +62,7 @@
** finished, without interrupt
**
** ## Locking
** The ProcDispatcher uses an "inner and outer capsule" design, and both layers are locked independently.
** The SteamDispatcher uses an "inner and outer capsule" design, and both layers are locked independently.
** On the outer layer, locking ensures sanity of the control data structures, while locking on the inner
** layer guards the communication with the Session Loop Thread, and coordinates sleep wait and notification.
** As usual with Lumiera's Thread wrapper, the management of the thread's lifecycle itself, hand-over of
@ -73,7 +73,7 @@
** is a private detail of the performing thread. The lock is acquired solely for checking or leaving
** the wait state and when fetching the next command from queue.
**
** @see ProcDispatcher
** @see SteamDispatcher
** @see DispatcherLooper_test
** @see CommandQueue_test
**
@ -82,7 +82,7 @@
#include "lib/error.hpp"
#include "include/logging.h"
#include "steam/control/proc-dispatcher.hpp"
#include "steam/control/steam-dispatcher.hpp"
#include "steam/control/command-dispatch.hpp"
#include "steam/control/command-queue.hpp"
#include "steam/control/looper.hpp"
@ -106,7 +106,7 @@ namespace control {
/********************************************************************//**
* PImpl within ProcDispatcher to implement the _Session Loop Thread._
* PImpl within SteamDispatcher to implement the _Session Loop Thread._
* During the lifetime of this object...
* - the SessionCommandService is offered to enqueue commands
* - the Session Loop thread dispatches commands and triggers the Builder
@ -324,15 +324,15 @@ namespace control {
/** storage for Singleton access */
lib::Depend<ProcDispatcher> ProcDispatcher::instance;
lib::Depend<SteamDispatcher> SteamDispatcher::instance;
/* ======== ProcDispatcher implementation ======== */
/* ======== SteamDispatcher implementation ======== */
ProcDispatcher::ProcDispatcher() { }
ProcDispatcher::~ProcDispatcher() { }
SteamDispatcher::SteamDispatcher() { }
SteamDispatcher::~SteamDispatcher() { }
/** starting the ProcDispatcher means to start the session subsystem.
/** starting the SteamDispatcher means to start the session subsystem.
* @return `false` when _starting_ failed since it is already running...
* @remark this function implements the start operation for the »session subsystem«.
* More specifically, this operation starts a new thread to perform the
@ -341,7 +341,7 @@ namespace control {
* while opening the SessionCommand facade.
*/
bool
ProcDispatcher::start (Subsys::SigTerm termNotification)
SteamDispatcher::start (Subsys::SigTerm termNotification)
{
Lock sync(this);
if (runningLoop_) return false;
@ -350,7 +350,7 @@ namespace control {
new DispatcherLoop (
[=] (string* problemMessage)
{
ProcDispatcher::endRunningLoopState();
SteamDispatcher::endRunningLoopState();
termNotification(problemMessage);
}));
@ -365,7 +365,7 @@ namespace control {
* started and is not (yet) completely terminated.
*/
bool
ProcDispatcher::isRunning()
SteamDispatcher::isRunning()
{
Lock sync(this);
return bool(runningLoop_);
@ -376,7 +376,7 @@ namespace control {
* @note the immediate consequence is to close SessionCommandService
*/
void
ProcDispatcher::requestStop() noexcept
SteamDispatcher::requestStop() noexcept
{
try {
Lock sync(this);
@ -390,21 +390,21 @@ namespace control {
/** @internal clean-up when leaving the session loop thread.
* This function is hooked up in to the termination callback,
* and is in fact the only one to delete the loop PImpl. We
* take the (outer) lock on ProcDispatcher to ensure no one
* take the (outer) lock on SteamDispatcher to ensure no one
* commits anything to the DispatcherLoop object while being
* deleted. The call itself, while technically originating
* from within DispatcherLoop::runSessionThread(), relies
* solely on stack based context data and is a tail call.
*/
void
ProcDispatcher::endRunningLoopState()
SteamDispatcher::endRunningLoopState()
{
Lock sync(this);
if (runningLoop_)
runningLoop_.reset(); // delete DispatcherLoop object
else
WARN (command, "clean-up of DispatcherLoop invoked, "
"while ProcDispatcher is not marked as 'running'. "
"while SteamDispatcher is not marked as 'running'. "
"Likely an error in lifecycle logic, as the only one "
"intended to delete this object is the loop thread itself.");
}
@ -419,7 +419,7 @@ namespace control {
* is stored and applied accordingly later, when the loop is fired up.
*/
void
ProcDispatcher::activate()
SteamDispatcher::activate()
{
Lock sync(this);
active_ = true;
@ -435,7 +435,7 @@ namespace control {
* about to dismantled, it is mandatory to awaitDeactivation()
*/
void
ProcDispatcher::deactivate()
SteamDispatcher::deactivate()
{
Lock sync(this);
active_ = false;
@ -451,7 +451,7 @@ namespace control {
* @throw error::Fatal when a deadlock due to such a recursive call can be detected
*/
void
ProcDispatcher::awaitDeactivation()
SteamDispatcher::awaitDeactivation()
{
Lock sync(this);
if (runningLoop_)
@ -461,7 +461,7 @@ namespace control {
/** discard any commands waiting in the dispatcher queue */
void
ProcDispatcher::clear()
SteamDispatcher::clear()
{
Lock sync(this);
if (not empty())
@ -474,7 +474,7 @@ namespace control {
bool
ProcDispatcher::empty() const
SteamDispatcher::empty() const
{
Lock sync(this);
return not runningLoop_

22
src/steam/control/proc-dispatcher.hpp → src/steam/control/steam-dispatcher.hpp
View file

@ -1,5 +1,5 @@
/*
PROC-DISPATCHER.hpp - Steam-Layer command dispatch and execution
STEAM-DISPATCHER.hpp - Steam-Layer command dispatch and execution
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
@ -21,9 +21,9 @@
*/
/** @file proc-dispatcher.hpp
/** @file steam-dispatcher.hpp
** Dispatch and execute mutation operations on the High-level model.
** The ProcDispatcher is the application facility to back and support working
** The SteamDispatcher is the application facility to back and support working
** on the Session. While the session itself is just a data structure, _operating_
** the session means to process commands changing that data structure and it means
** to evaluate the _session model_ and _build_ a render nodes network in accordance
@ -31,11 +31,11 @@
** and this is what we call the "session subsystem" within the application. When this is
** running, the SessionCommand facade is opened, accepting commands to work on the session.
** Such commands are passed through a dispatch queue to ensure consistent session state
** and to force strictly sequential processing of commands. Moreover, the ProcDispatcher's
** and to force strictly sequential processing of commands. Moreover, the SteamDispatcher's
** responsibility is to care for triggering the Builder after any changes induced by those
** commands. The Builder is guaranteed to run _eventually_, yet with some leeway.
**
** Talking of state, independent of the lifecycle running state, the ProcDispatcher can be
** Talking of state, independent of the lifecycle running state, the SteamDispatcher can be
** _activated or deactivated_. In active state, commands are dequeued and processed, while
** in inactive state commands are just accepted and queued, assuming the SessionCommand
** interface is currently opened. This activation state is controlled by the session
@ -45,7 +45,7 @@
**
** @see Command
** @see Session
** @see proc-dispatcher.cpp for details of operational semantics
** @see steam-dispatcher.cpp for details of operational semantics
**
*/
@ -81,14 +81,14 @@ namespace control {
* contents into a render nodes network. Also embedded herein is
* the implementation of steam::control::SessionCommandService
*/
class ProcDispatcher
class SteamDispatcher
: public lib::Sync<>
{
unique_ptr<DispatcherLoop> runningLoop_;
bool active_{false};
public:
static lib::Depend<ProcDispatcher> instance;
static lib::Depend<SteamDispatcher> instance;
bool start (Subsys::SigTerm);
bool isRunning();
@ -104,9 +104,9 @@ namespace control {
private:
void endRunningLoopState();
~ProcDispatcher();
ProcDispatcher();
friend class lib::DependencyFactory<ProcDispatcher>;
~SteamDispatcher();
SteamDispatcher();
friend class lib::DependencyFactory<SteamDispatcher>;
};

12
src/steam/facade.cpp
View file

@ -36,7 +36,7 @@
** - to operate on the session, use the steam::control::SessionCommand facade
** - playback and render operations can be operated by the lumiera::Play facade
**
** @see ProcDispatcher
** @see SteamDispatcher
** @see OutputDirector
** @see subsys.hpp
** @see main.cpp
@ -46,7 +46,7 @@
#include "steam/facade.hpp"
#include "lib/depend.hpp"
#include "steam/control/proc-dispatcher.hpp"
#include "steam/control/steam-dispatcher.hpp"
#include "steam/play/output-director.hpp"
#include <string>
@ -58,7 +58,7 @@ namespace steam {
using std::unique_ptr;
using lumiera::Subsys;
using lumiera::Option;
using steam::control::ProcDispatcher;
using steam::control::SteamDispatcher;
class SessionSubsystem
@ -78,19 +78,19 @@ namespace steam {
bool
start (Option&, Subsys::SigTerm termNotification) override
{
return ProcDispatcher::instance().start (termNotification);
return SteamDispatcher::instance().start (termNotification);
}
void
triggerShutdown() noexcept override
{
ProcDispatcher::instance().requestStop();
SteamDispatcher::instance().requestStop();
}
bool
checkRunningState() noexcept override
{
return ProcDispatcher::instance().isRunning();
return SteamDispatcher::instance().isRunning();
}
};

8
src/steam/mobject/session/sess-manager-impl.cpp
View file

@ -42,7 +42,7 @@
#include "steam/mobject/session.hpp"
#include "steam/mobject/session/sess-manager-impl.hpp"
#include "steam/mobject/session/lifecycle-advisor.hpp"
#include "steam/control/proc-dispatcher.hpp"
#include "steam/control/steam-dispatcher.hpp"
#include "steam/config-resolver.hpp"
#include "steam/asset/timeline.hpp"
#include "common/query/defs-manager.hpp"
@ -148,14 +148,14 @@ namespace session {
void
openSessionInterface() override
{
control::ProcDispatcher::instance().activate();
control::SteamDispatcher::instance().activate();
}
void
closeSessionInterface() override
{
control::ProcDispatcher::instance().deactivate();
control::SteamDispatcher::instance().deactivate();
}
@ -173,7 +173,7 @@ namespace session {
void
commandLogCheckpoint() override
{ //////////////////////////////////////// TICKET #697
control::ProcDispatcher::instance().awaitDeactivation();
control::SteamDispatcher::instance().awaitDeactivation();
INFO (command, " Session shutdown. Command processing stopped.");
}

2
src/steam/mobject/session/session-services.cpp
View file

@ -85,7 +85,7 @@ namespace session {
* @param placementID hash-ID, typically from a PlacementRef
* @throw error::Invalid if the ID isn't resolvable
* @note the returned ref is guaranteed to be valid and usable
* only \em now, which means, by virtue of the ProcDispatcher
* only \em now, which means, by virtue of the SteamDispatcher
* and command processing, during this operation. It can be
* used to invoke an operation, but should never be stored;
* rather, client code should create an MObjectRef, if

4
tests/core/steam/control/command-basic-test.cpp
View file

@ -1,5 +1,5 @@
/*
CommandBasic(Test) - checking simple ProcDispatcher command definition and execution
CommandBasic(Test) - checking simple SteamDispatcher command definition and execution
Copyright (C) Lumiera.org
2009, Hermann Vosseler <Ichthyostega@web.de>
@ -88,7 +88,7 @@ namespace test {
*
* @see control::Command
* @see control::CommandDef
* @see mobject::ProcDispatcher
* @see control::SteamDispatcher
*/
class CommandBasic_test : public Test
{

4
tests/core/steam/control/command-instance-manager-test.cpp
View file

@ -107,7 +107,7 @@ namespace test {
/***********************************************************************//**
* @test CommandInstanceManager is responsible for providing individual
* clone copies from a basic command definition, to be bound with
* actual arguments and finally handed over to the ProcDispatcher
* actual arguments and finally handed over to the SteamDispatcher
* for invocation.
*
* @see steam::control::CommandInstanceManager
@ -201,7 +201,7 @@ namespace test {
/** @test relation of command, instanceID and concrete instance
* The CommandInstanceManager provides the notion of a _current instance,_
* which can then be used to bind arguments. When done, it will be _dispatched,_
* and then go through the ProcDispatcher's CommandQueue (in this test, we use
* and then go through the SteamDispatcher's CommandQueue (in this test, we use
* just a dummy Fixture, which only enqueues the dispatched commands.
*
* The following notions need to be kept apart

6
tests/core/steam/control/command-queue-test.cpp
View file

@ -1,5 +1,5 @@
/*
CommandQueue(Test) - verify functionality of ProcDispatcher queue component
CommandQueue(Test) - verify functionality of SteamDispatcher queue component
Copyright (C) Lumiera.org
2016, Hermann Vosseler <Ichthyostega@web.de>
@ -61,13 +61,13 @@ namespace test {
/******************************************************************************//**
* @test verify proper working of queue management used within ProcDispatcher.
* @test verify proper working of queue management used within SteamDispatcher.
* - can enqueue and dequeue command messages
* - handling of priority messages
*
* @see CommandQueue
* @see DispatcherLoop
* @see ProcDispatcher
* @see SteamDispatcher
* @see DispatcherLooper_test
*/
class CommandQueue_test : public Test

20
tests/core/steam/control/command-use2-test.cpp
View file

@ -39,7 +39,7 @@
extern "C" {
#include "common/interfaceregistry.h"
}
#include "steam/control/proc-dispatcher.hpp"
#include "steam/control/steam-dispatcher.hpp"
#include "include/session-command-facade.h"
#include <functional>
@ -214,24 +214,24 @@ namespace test {
/** @test simplified integration test of command dispatch
* - performs the minimal actions necessary to start the session loop thread
* - then issues a test command, which will be queued and dispatched
* by the ProcDispatcher. Like in the real application, the command
* by the SteamDispatcher. Like in the real application, the command
* executions happens in the dedicated session loop thread, and thus
* we have to wait a moment, after which execution can be verified.
* - finally the ProcDispatcher is signalled to shut down.
* - finally the SteamDispatcher is signalled to shut down.
* @see SessionCommandFunction_test for much more in-depth coverage of this aspect
*/
void
check_DispatcherInvocation()
{
CHECK (not ProcDispatcher::instance().isRunning());
CHECK (not SteamDispatcher::instance().isRunning());
lumiera_interfaceregistry_init();
lumiera::throwOnError();
#define __DELAY__ usleep(10000);
bool thread_has_ended{false};
ProcDispatcher::instance().start ([&] (string*) { thread_has_ended = true; });
SteamDispatcher::instance().start ([&] (string*) { thread_has_ended = true; });
CHECK (ProcDispatcher::instance().isRunning());
CHECK (SteamDispatcher::instance().isRunning());
CHECK (not thread_has_ended);
//----Session-Loop-Thread-is-running------------------------
@ -251,12 +251,12 @@ namespace test {
//----Session-Loop-Thread-is-running------------------------
// shut down the ProcDispatcher...
CHECK (ProcDispatcher::instance().isRunning());
ProcDispatcher::instance().requestStop();
// shut down the SteamDispatcher...
CHECK (SteamDispatcher::instance().isRunning());
SteamDispatcher::instance().requestStop();
__DELAY__ // wait a moment for the other thread to terminate...
CHECK (not ProcDispatcher::instance().isRunning());
CHECK (not SteamDispatcher::instance().isRunning());
CHECK (thread_has_ended);
lumiera_interfaceregistry_destroy();

4
tests/core/steam/control/dispatcher-looper-test.cpp
View file

@ -1,5 +1,5 @@
/*
DispatcherLooper(Test) - verify loop control and timing functionality of ProcDispatcher
DispatcherLooper(Test) - verify loop control and timing functionality of SteamDispatcher
Copyright (C) Lumiera.org
2016, Hermann Vosseler <Ichthyostega@web.de>
@ -90,7 +90,7 @@ namespace test {
/******************************************************************************//**
* @test verify encapsulated control logic of ProcDispatcher.
* @test verify encapsulated control logic of SteamDispatcher.
* - fusing of conditions for the pthread waiting condition
* - detection and handling of work states
* - management of builder run triggers

36
tests/core/steam/control/session-command-function-test.cpp
View file

@ -26,7 +26,7 @@
** This is a test combining several components to operate similar as in the real application,
** while still relying upon an unit-test like setup. The goal is to cover how _session commands_
** are issued from an access point (CoreService) in the UI backbone, passed on through an
** abstraction interface (the SessionCommand facade), handed over to the ProcDispatcher,
** abstraction interface (the SessionCommand facade), handed over to the SteamDispatcher,
** which, running within a dedicated thread (the »session loop thread«), enqueues all
** these commands and dispatches them one by one.
**
@ -60,7 +60,7 @@
** tuned to work satisfactory in practice. This whole approach can only work, because each
** Posix locking call actually requires the runtime system to issue a read/write barrier,
** which are known to have global effects on the relevant platforms (x86 and x86_64).
** And because the production relevant code in ProcDispatcher uses sufficient (in fact
** And because the production relevant code in SteamDispatcher uses sufficient (in fact
** even excessive) locking, the state variables of the test fixture are properly synced
** by sideeffect.
**
@ -79,7 +79,7 @@ extern "C" {
#include "common/interfaceregistry.h"
}
#include "steam/control/proc-dispatcher.hpp"
#include "steam/control/steam-dispatcher.hpp"
#include "steam/control/command-def.hpp"
#include "include/session-command-facade.h"
#include "vault/thread-wrapper.hpp"
@ -180,7 +180,7 @@ namespace test {
* - verify that commands are really executed single-threaded
*
* @see steam::SessionSubsystem
* @see ProcDispatcher
* @see SteamDispatcher
* @see CommandQueue_test
* @see AbstractTangible_test::invokeCommand()
*/
@ -233,15 +233,15 @@ namespace test {
void
startDispatcher()
{
CHECK (not ProcDispatcher::instance().isRunning());
CHECK (not SteamDispatcher::instance().isRunning());
ProcDispatcher::instance().start ([&] (string* problemMessage)
{
CHECK (isnil (*problemMessage));
thread_has_ended = true;
});
SteamDispatcher::instance().start ([&] (string* problemMessage)
{
CHECK (isnil (*problemMessage));
thread_has_ended = true;
});
CHECK (ProcDispatcher::instance().isRunning());
CHECK (SteamDispatcher::instance().isRunning());
CHECK (not thread_has_ended);
}
bool thread_has_ended{false};
@ -251,11 +251,11 @@ namespace test {
void
stopDispatcher()
{
CHECK (ProcDispatcher::instance().isRunning());
ProcDispatcher::instance().requestStop();
CHECK (SteamDispatcher::instance().isRunning());
SteamDispatcher::instance().requestStop();
__DELAY__
CHECK (not ProcDispatcher::instance().isRunning());
CHECK (not SteamDispatcher::instance().isRunning());
CHECK (thread_has_ended);
}
@ -395,14 +395,14 @@ namespace test {
usleep(MAX_RAND_DELAY_us * NUM_INVOC_PER_THRED / 2);
// stop the dispatching to cause the queue to build up...
ProcDispatcher::instance().deactivate();
ProcDispatcher::instance().awaitDeactivation();
SteamDispatcher::instance().deactivate();
SteamDispatcher::instance().awaitDeactivation();
__DELAY__
ProcDispatcher::instance().activate();
SteamDispatcher::instance().activate();
__DELAY__
while (not ProcDispatcher::instance().empty());
while (not SteamDispatcher::instance().empty());
__DELAY__
CHECK (testCommandState - prevState == Time(expectedOffset));