Actors & concurrency
Actors are the center of Acton's model for mutable state and concurrency. If you want to understand how Acton programs stay structured as they grow, start here.
Start with the basic actor main(env) pattern. The core
model is simple: an actor owns state, handles one message at a time,
and communicates with other actors by calling their methods.
This is also the closest Acton replacement for Rust-style lifetime thinking: actors own mutable state, capability references are passed explicitly, and the runtime manages ordinary object lifetime.
The important guarantee is local seriality: within one actor, state
changes are observed as if messages were handled one at a time. That is
why var can hold mutable state without introducing the kind
of shared-memory races that make threaded code hard to reason about.
The actor boundary is doing real work here: mutation stays local, while
concurrency appears only in the relationships between actors.
Viewed that way, many Acton features are the same model in different
forms. Sync and async calls, await, delayed callbacks with
after, and lifecycle hooks all control when new work is
placed into an actor's mailbox and when another actor is allowed to make
progress. What Acton does not promise is one global timeline across the
whole program. Ordering is local to each actor unless your own protocol
establishes something stronger.
This section covers:
- how actors own state and methods
- how the root actor starts a program
- how actors talk to each other
- how delayed work and cleanup fit into actor code
- how concurrency works without shared mutable memory
Read these pages next:
- Actors
- Root Actor
- Lifetime
- Attributes
self- Actor methods
- Sync Method calls
- Async Method calls
- Control flow in an async actor world
- after / sleep
- Concurrency
- Cleanup
Effect annotations such as pure, mut, proc, and action are
documented under Working with types.