Crates.io | rex-sm |
lib.rs | rex-sm |
version | 0.7.0 |
source | src |
created_at | 2024-01-04 06:33:06.161197 |
updated_at | 2024-10-15 18:31:25.782677 |
description | Hierarchical state machine |
homepage | |
repository | |
max_upload_size | |
id | 1088208 |
size | 140,264 |
(<State>, <Event>)
formatStateMachine
s are first registered with the StateMachineManager
, which I will refer
to as simply the Manager
. Every call to Manager::cycle()
processes a single event.
A single event corresponds to running on a single state machine. The Manager
accesses
the contents of the Controller
and manipulates it. A single Controller
is shared
amongst all state machines registered with the Manager
.
There are two types of events UserEvent
s and SystemEvent
s. UserEvent
s are passed to
StateMachine::cycle()
while SystemEvent
s are not. StateMachine::cycle()
accepts a
&mut Controller
and a UserEvent
. The StateMachine
uses the functions in the Controller
to add/remove events from the event queue; all functions do this except for timer related functions.
SystemEvent
s are consumed by the manager and used to modify the Controller
internals or send
data or notifications to outside the state machine group.
decoupling state machine input processing from a given state’s current enumerations
state signaling that all feeds into the same sink (the manager’s
signal_queue
) ; this allows lifts and transits to be processed
homogeneously thus avoiding type opacity through Box<dyn Signal>
I/O
Input
(handles both external and internal events)Signal {
id: StateId<K>,
input: I,
}
Two outputs:
Signal
output (events meant to be processed as inputs for other state machines)
Notification
output (events meant to be processed by anything that is not a state machine fed by a given signal_queue
)
StateMachineManager
owns:StateStore
)StateMachineManager
is responsible for:routing Signal
s to the appropriate state machines
Injecting ProcessorContext
s into the state machines: this action is what allows state machines to cycle concurrently
StateStore
is responsible for:Arc<Mutex<_>>
containers.StateStore
storage to:Create multiple indices (Through fresh DashMap
key insertions) pointing to the same tree by incrementing the Arc
count and inserting a new entry per child node
Allows independent interior mutability per state tree, decoupling unrelated states from resource contention
TimeoutManager
(in development)Considerations:
StateId<K>
, State machines should not have
to keep track of Operation::Set(Instant::now())
emitted to notifications.
Thus, all timers should be indexable by StateId<K>
.Operation::Set
for the same StateId<K>
should override an old timer.Signal
that is pertinent to the related state machine.Approach:
TimeoutManager
implements a per tick polling approach to resolving
timeoutsTimeoutLedger
TimeoutLedger
contains a BTreeMap
that indexes IDs by Instant
and a
HashMap
that indexes Instant
s by ID This double indexing allows timeout
cancellations to go through without providing the Instant
that they were
meant to remove