[Accepted] SE-0336: Distributed Actor Isolation

Evolution Announcements
1

Hi everyone. The review for SE-0336: Distributed actor isolation has completed, and the Core Team has decided to accept the proposal. This proposal is the first step in a series of proposals related to distributed actors, and establishes the basic language model for defining and interacting with them. Review discussion raised some questions about the proposed design:

  • The proposal specifies that distributed actors are declared explicitly as such, using the keyword modifier sequence distributed actor, instead of being a variation of a regular actor conforming to a Distributable protocol. The design choices we made for "local" actors allow for flexibility and expressivity in cross-actor calls that aren't possible for remote actors. Since distributed actors are intended to be location-agnostic, there are inherent constraints on messaging a distributed actor, such as it needing to be async and throws regardless of the isolatedness and/or fallibility of the underlying method implementation, and those constraints lead to fundamental differences in how local and distributed actor types work. Thus there isn't a clear "is-a" relationship between them. However, we expect distributed actors will be designed as such up front, and that there's no free lunch for turning a local actor into a distributed one—no matter what, they will fundamentally have to update the actor's interface and clients to work in a distributed context, with the changes to responsiveness and reliability that implies, so the distinction at the language level doesn't impede evolution, and is acceptable in order to make local-only actors more expressive.

  • Along similar lines, the proposal requires methods and properties that can be invoked remotely to be explicitly declared distributed func or distributed var, instead of making every method remotely callable, or relying on existing access control modifiers. We think this is the right tradeoff: it makes it clear what the RPC surface area of a distributed actor is, just by looking for the distributed members, and reduces the likelihood of accidentally introducing security bugs or long-term API liabilities from unintentionally exposing methods as remote entry points. Furthermore, the implementors of the proposal tried the distributed-by-default approach extensively before bringing the proposal to review, and found that it did not work well for a variety of technical reasons.

  • The wording of the distributed modifier itself came under debate. Since the underlying reference in a value of distributed actor type could be local and is not necessarily actually remote, one could argue that distributable, or some other term that captured that ambivalence, would be more technically correct. On the other hand, "distributed actor" is an established term of art, and we didn't see a compelling alternative that really increases clarity.

  • There were questions of whether the proposal should tie distributed actors' serialization requirements more tightly to Codable. Although Codable is the lingua franca for serialization in Swift, we want to retain flexibility for distributed actors to work well with other serialization frameworks that don't use Codable, for them to utilize the preferred IPC/RPC mechanisms of host platforms where appropriate, and for them to be able to evolve with the language ecosystem as serialization best practices do.

  • The proposal specifies a whenLocal operation, which checks whether a reference to a distributed actor is running locally, and executes its block with static knowledge that the reference is local, giving additional direct access to the instance's stored properties and nonisolated/nonthrowing APIs. It also suggests, as a future direction, that local could be a type modifier, allowing for local actor references to be propagated through the type system, and reviewers noted that this might render the whenLocal construct as a special case obsolete. For the time being, whenLocal is an important operation, and it could be transparently changed to be defined using the more general type system feature if that is later implemented, proposed, and accepted, so the core team sees no problem with accepting the functionality now.

The review discussion also explored future directions for distributed actors, such as versioning, one-way messaging, and supervisor models, which we expect to be addressed by further proposals building on top of the foundation of this one. Thank you to everyone who contributed to the review!

22 Likes