#include "steam/control/looper.hpp"

Description

Encapsulated control logic for the session thread loop.

This helper component was factored out from the loop body for sake of clarity and to allow unit testing of the logic in isolation. It is based on logical relations together with the following assumptions

Looper::shallLoop controls the loop's while condition
at the begin of the loop the thread possibly enters a blocking wait state; the wake-up condition is provided by Looper::requireAction.
then, in the actual loop body, depending on the predicates calculated here, either the builder run is triggered, or a single command is dispatched from the queue to work on the session.
after returning from these active operations, at the end of the loop, the state evaluation is updated by Looper::markStateProcessed

Warning: the Looper is not threadsafe, since it is intended to be run exclusively from the Session working thread.

See also: DispatcherLoop::run()

Definition at line 114 of file looper.hpp.

Public Member Functions
template<class FUN >
	Looper (FUN determine_commands_are_waiting)

void	enableProcessing (bool yes=true)

milliseconds	getTimeout () const

bool	hasPendingChanges () const
	< "check point"

bool	idleBuild () const

bool	isDisabled () const

bool	isDying () const

bool	isIdle () const

bool	isWorking () const

void	markStateProcessed ()
	invoking this function signals that all consequences of past state changes have been processed and are duly resolved. More...

bool	requireAction ()
	state fusion to control (timed) wait

bool	runBuild () const

bool	shallLoop () const
	state fusion to control looping

void	triggerShutdown ()

bool	useTimeout () const

Private Types
using	Predicate = std::function< bool(void)>

Private Member Functions
bool	forceBuild () const

void	startBuilderTimeout ()

Static Private Member Functions
static uint	slowdownFactor ()

static uint	wakeTimeout_ms ()

Private Attributes
bool	disabled_ = false

TimeVar	gotDirty_ = Time::NEVER

Predicate	hasCommandsPending_

bool	hasWork_ = false

bool	inChange_ = false

bool	isDirty_ = false

bool	shutdown_ = false

Member Function Documentation

◆ markStateProcessed()

void markStateProcessed ( )

inline

invoking this function signals that all consequences of past state changes have been processed and are duly resolved.

Remarks: the implementation actually does not need to watch out for command processing state directly, only the managing of builder runs requires active state transitions here. When the conditions for triggering the Builder are met, control flow typically just has emptied the command queue. Thus we need to let one invocation pass by; the next loop iteration will begin after waking up from a short sleep and trigger the build, so the following (second) invocation can clear the builder dirty state.

Definition at line 174 of file looper.hpp.

Referenced by DispatcherLoop::runSessionThread(), and DispatcherLooper_test::verifyBuilderStart().

Here is the caller graph for this function:

◆ wakeTimeout_ms()

uint wakeTimeout_ms ( )

inlinestaticprivate

establish the typical timeout for idle sleep. 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 that further commands trickling in get a chance to be enqueued before the builder run effectively blocks command processing. Add to this the typical average running time of the builder, to get the reaction period visible to the user as update response delay within the UI.