3e504d3969
Ran through a few passes of the 'happy path' with the debugger, ran flamegraph analysis: we are very much overdoing the atomic ring buffer channels. They may be fast for concurrency across threads, but we don't necessarily need that for every occasion.
55 lines
2.9 KiB
Markdown
55 lines
2.9 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 may make this a `![no_std]` library, but the MVP will use the
|
|
memory allocator and threading provided by the rust standard library.
|
|
|
|
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.
|
|
|
|
# FIXME
|
|
This is slightly obsolete. Was necessary in order to concentrate on getting the basic skeleton up, now it's a distraction and unreliable.
|
|
After getting the benches/etc finished, move this into an `ARCHITECTURE.md` file, have it make sense.
|
|
|
|
|
|
## 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
|
|
Implemented as a barebones atomic ring buffer. The router is responsible for inserting messages.
|
|
|
|
- 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
|
|
|
|
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 good start is a backpressure strategy: after loading, process messages until mailbox is empty or size drops below a threshold (e.g., "drain to 50%").
|
|
|
|
- A message router:
|
|
the router is responsible for ensuring messages posted by actors get delivered to the appropriate inbox.
|
|
|
|
- An atomic ring buffer containing thread-safe references to actors that are not currently loaded. Actors are popped off the buffer, messages are
|
|
processed, and the reference is returned to the buffer/queue before the next actor is loaded.
|
|
|
|
## Router
|
|
|
|
The router is the engine for message delivery. It posesses:
|
|
|
|
- An actor address book:
|
|
The address book maps actor ids to `Sender` references that can be used to deliver messages to the actor inbox.
|
|
|
|
- Its own inbox:
|
|
The router possesses its own mpsc queue where references to messages are stored. The router will process this queue by dereferencing and writing directly into the recipient's inbox buffer.
|
|
|