| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
This change moves the simulator terminology from logical processes to
simulation domains. This prevents the clash with "processes" that we are
trying to simulate.
In addition, simulation domains allows us to reduce the amount of
boilerplate and instead allows for simulation modelled using standard
techniques.
|
|
This change makes the ProcessContext implement the CoroutineScope in
order to launch local coroutines bound to the lifecycle of the logical
process.
|
|
This change adds a log property to the ProcessContext which allows the
user to access a Logger instance that is tied to a particular logical
process.
|
|
This change adds helper methods for simplifying the request-response
pattern commonly used in models.
|
|
This change adds experimental support for selecting on ports. This
allows the user to receive messages from multiple channels at the same
time.
|
|
This change introduces the revised API design for version 2.0 of the
OpenDC simulator. This version drops built-in support for Java and
instead opts to build on Kotlin coroutines to simplify the API surface.
During development of and experimentation with the previous API for version
2.x, we found that the design based on Akka Typed was too limiting and caused
too much boilerplate for the models we needed to implement. Essential
patterns such as request-response were found to be hard to implement
with only a single mailbox. Moveover, limiting each actor's mailbox to a
single type hindered composition and often resulted in unchecked casts
or the type being changed to `Any`, eliminating the type-safety of the
API.
In this revised API design, a simulation is now represented as the interplay of
logical processes that communicate via multiple message passing channels.
We use Kotlin coroutines to describe the behavior of the processes.
The API has been design from the start to take into account
distributed/parallel simulations by disallowing messages from arbitrary
processes, which was possible in the previous design. Instead, the
'communication graph' is known during runtime as procsses must register
themselves before being able to send/receive messages to/from channels.
We are still figuring out process/channel identity and supervision. Currently,
all logical processes run on a single level, instead of being
hierachical. However, this might change in the future.
|
|
This change renames the main module of the odcsim library to odcsim-api,
since it mainly contains the interfaces to be used by consumers of the
API and implemented by the various frameworks.
|
