See: Description
| Interface | Description |
|---|---|
| Modulator<Ctx> | |
| Module<Ctx> |
A Module has 5 ActionMethods = [initModule(), start(), runOnce(), stop(), releaseModule()]
and 8 formal states.
|
| Enum | Description |
|---|---|
| Module.State |
Micro-framework of defined execution lifecycles for parallel state machines. After init+start, Module machines expect their runOnce methods to be called as often as practically possible (given machine resources and priorities). Modules endeavor to make "runOnce" perform the smallest possible consistent chunk of work. The logic for start+stop of a Module is completely orthogonal to its runOnce business payload.
Modules are generally run by a Modulator, which typically will own a single JVM work thread that it uses for all callbacks into its Modules. The Modulator provides an API for clients to start and stop modules. A particular Modulator may employ any kind of fairness and priority policies.
Module has a pointer to a single parent Modulator of generic type. Thus, Modules are parametrized by the types of Modulators they require. It is possible to construct a pattern where a Module's callbacks obtain important resources by request from its parent-Mu, which may implement useful synchronization policies for a collection of modules following the pattern.
Copyright © 2010-2015. All Rights Reserved.