EnTT 3.14.0
|
Processes are a useful tool to work around the strict definition of a system and introduce logic in a different way, usually without resorting to other component types.
EnTT
offers minimal support to this paradigm by introducing a few classes used to define and execute cooperative processes.
A typical task inherits from the process
class template that stays true to the CRTP idiom. Moreover, derived classes specify what the intended type for elapsed times is.
A process should expose publicly the following member functions whether needed (note that it isn't required to define a function unless the derived class wants to override the default behavior):
void update(Delta, void *);
This is invoked once per tick until a process is explicitly aborted or ends either with or without errors. Even though it's not mandatory to declare this member function, as a rule of thumb each process should at least define it to work properly. The void *
parameter is an opaque pointer to user data (if any) forwarded directly to the process during an update.
void init();
This is invoked when the process joins the running queue of a scheduler. It happens usually as soon as the process is attached to the scheduler if it's a top level one, otherwise when it replaces its parent if it's a continuation.
void succeeded();
This is invoked in case of success, immediately after an update and during the same tick.
void failed();
This is invoked in case of errors, immediately after an update and during the same tick.
void aborted();
This is invoked only if a process is explicitly aborted. There is no guarantee that it executes in the same tick, it depends solely on whether the process is aborted immediately or not.
Derived classes can also change the internal state of a process by invoking succeed
and fail
, as well as pause
and unpause
the process itself.
All these are protected member functions made available to manage the life cycle of a process from a derived class.
Here is a minimal example for the sake of curiosity:
Lambdas and functors can't be used directly with a scheduler because they aren't properly defined processes with managed life cycles.
This class helps in filling the gap and turning lambdas and functors into full-featured processes usable by a scheduler.
The function call operator has a signature similar to the one of the update
function of a process but for the fact that it receives two extra callbacks to invoke whenever a process terminates with success or with an error:
Parameters have the following meaning:
delta
is the elapsed time.data
is an opaque pointer to user data if any, nullptr
otherwise.succeed
is a function to call when a process terminates with success.fail
is a function to call when a process terminates with errors.Both succeed
and fail
accept no parameters at all.
Note that usually users shouldn't worry about creating adaptors at all. A scheduler creates them internally each and every time a lambda or a functor is used as a process.
A cooperative scheduler runs different processes and helps managing their life cycles.
Each process is invoked once per tick. If it terminates, it's removed automatically from the scheduler and it's never invoked again. Otherwise, it's a good candidate to run one more time the next tick.
A process can also have a child. In this case, the parent process is replaced with its child when it terminates and only if it returns with success. In case of errors, both the parent process and its child are discarded. This way, it's easy to create chain of processes to run sequentially.
Using a scheduler is straightforward. To create it, users must provide only the type for the elapsed times and no arguments at all:
Otherwise, the scheduler
alias is also available for the most common cases. It uses std::uint32_t
as a default type:
The class has member functions to query its internal data structures, like empty
or size
, as well as a clear
utility to reset it to a clean state:
To attach a process to a scheduler there are mainly two ways:
If the process inherits from the process
class template, it's enough to indicate its type and submit all the parameters required to construct it to the attach
member function:
Otherwise, in case of a lambda or a functor, it's enough to provide an instance of the class to the attach
member function:
In both cases, the scheduler is returned and its then
member function can be used to create chains of processes to run sequentially.
As a minimal example of use:
To update a scheduler and therefore all its processes, the update
member function is the way to go:
In addition to these functions, the scheduler offers an abort
member function that is used to discard all the running processes at once: