35 lines
1.6 KiB
Markdown
35 lines
1.6 KiB
Markdown
|
# Design goals
|
||
|
|
Get as much usability and speed as possible while keeping line count low. Aim for no footguns, ability to plug in
|
||
|
|
logic easily, and run near anywhere.
|
||
|
|
|
||
|
|
We are not building a new erlang/BEAM. Minimal feature set means spawning actor processes, not having supervisiors, lots of process
|
||
|
|
monitoring tools, prempting, etc.
|
||
|
|
|
||
|
|
## Actor model
|
||
|
|
|
||
|
|
An actor has:
|
||
|
|
|
||
|
|
- An inbox:
|
||
|
|
this is a mpsc channel that the runtime/router dumps messages into and the actor consumes when the runtime loads it
|
||
|
|
|
||
|
|
- an outbox channel connection:
|
||
|
|
this is a mpmc channel that is implemented by the runtime and router. Actors on this specific channel put responses and outgoing messages into this channel, to be routed to the given address.
|
||
|
|
|
||
|
|
- a growable and mutable state:
|
||
|
|
An actor owns some, from the runtime perspective, type erased bytes. The actor when processing messages can access its own state, but no other task can. This includes viewing.
|
||
|
|
|
||
|
|
- a set of functions for processing messages:
|
||
|
|
When the runtime loads the actor, it locks the inbox and attempts to process the messages therein.
|
||
|
|
|
||
|
|
## Runtime and Router
|
||
|
|
|
||
|
|
In order for an actor to consume and send messages, it is processed by a runtime. The runtime, in order to negotiate messages between
|
||
|
|
actors, possesses a router.
|
||
|
|
|
||
|
|
A runtime has:
|
||
|
|
|
||
|
|
- An actor processing thread(s):
|
||
|
|
the processor will mark an actor as busy, load its state and inbox, and begin consuming messages from the inbox. The number of messages consumed is determined by the runtime
|
||
|
|
|
||
|
|
- A message router:
|
||
|
|
the router is responsible for ensuring messages posted by actors get delivered to the appropriate inbox.
|