Hello everyone,
With the recent introduction of Swift concurrency, and most notably actors to the language, Swift gained powerful and foundational building blocks for expressing thread-safe concurrent programs. This proposal aims to extend Swift's actors with the ability to work equally well for distributed systems thanks to the introduction of distributed actors and location transparency associated with them.
- The proposal is fairly long, so please continue reading the full version linked below.
- You may skip reading the "appendix" section, it is not necessary to read unless one wants to understand the deeper implementation details of the proposal.
- We also include a sample application, showcasing this feature in action. We suggest giving it a try after reading the proposal. The provided transport implementation is only an example and is fairly incomplete, however the sample shows off all the interesting interactions with the language feature.
Distributed Actors
Introduction
Swift's actors are a relatively new building block for creating concurrent programs. The mutable state isolated by actors can only be interacted with by one task at any given time, eliminating a whole class of data races. But, the general actor model works equally well for distributed systems too.
This proposal introduces distributed actors, which are an extension of regular Swift actors that allows developers to take full advantage of the general actor model of computation. Distributed actors allow developers to scale their actor-based programs beyond a single process or node, without having to learn many new concepts.
Unlike regular actors, distributed actors take advantage of location transparency, which relies on a robust, sharable handle (or name) for each actor instance. These handles can reference actor instances located in a different program process, which may even be running on a different machine that is accessible over a network. After resolving an actor handle to a specific instance located somewhere, the basic interactions with the actor instance closely mirrors that of regular actors. Distributed actors abstract over the communication mechanism that enables location transparency, so that the implementation can be extended to different domains.
distributed actor Greeter {
distributed func greet(name: String) -> String {
"Hello, \(name)!"
}
}
Please continue reading in the full proposal.
Please post editorial changes, such as fixing typos or small mistakes should be pointed out in this swift-evolution PR.
In-depth discussions about transport implementation details are a huge topic on their own and likely to be better split off into their own dedicated threads. Thank you in advance for keeping this review focused on the language and runtime features.
Table of Contents
-
Distributed Actors
- Table of Contents
- Introduction
- Motivation
- Proposed solution
- Detailed design
- Alternatives Considered
- Acknowledgments & Prior Art
- Source compatibility
- Effect on ABI stability
- Effect on API resilience
- Changelog
-
Appendix (feel free to skip this, unless specifically interested in implementation details of the feature)
- Runtime implementation details
-
Future Directions
- The
AnyActor
marker protocol - Storing and requiring more specific Transport types
- Ability to customize parameter/return type requirements
- Resolving DistributedActor bound protocols
- Synthesis of
_remote
and well-definedEnvelope<Message>
functions - Support for
AsyncSequence
- Ability to hardcode actors to specific shared transport
- Actor Supervision
- The
- Related Work
- Background
// edit 1: fix links a little bit, to well formatted proposal