SE-0336: Distributed actor isolation

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

I should probably address core question right away:

• This proposal is not going to introduce "typed throws" to Swift.

Swift may or may not gain typed throws/errors in the future, and the runtime of distributed actors is prepared for such situation (if it ever happens), however currently typed throws do not exist and are not really planned.

---

@bobergj

Does the actual error type thrown for timeouts, network and serialization errors depend on the concrete DistributedActorSystem ?

Errors thrown are implementation dependent.

This proposal does not really dive into the runtime at all (that will be a follow-up proposal), but as a sneak peak I can say that we'd introduce an error protocol like follows:

/// Error protocol to which errors thrown by any `DistributedActorSystem` should conform.
@available(SwiftStdlib 5.6, *)
public protocol DistributedActorSystemError: Error {
}

In order to be able to differentiate errors thrown "by" the system (e.g. encoding error, timeouts, network failures), vs. ones transmitted from the remote side.

Transmitting errors itself is a long topic that we'll discuss more in the runtime proposal, but even then, it is very much up to a system implementation to decide how to deal with them. Transferring actual errors may be an optional opt-in feature, or a system may just return the error type, or no detailed information at all about a remote call throwing -- it is all very context dependent and has impact on security as well, so that's a very separate topic from actor isolation itself, so let's leave it for later discussions.

@bobergj

Codable is mentioned many times in this proposal, while alternatives such as protocol buffers are mentioned once or twice in passing.

Codable is mentioned not because of any relation with Apple runtimes, but because it is Swift's serialization story.

The design is specifically optimized to not tie distributed actors to Codable. We focus on it because it is mechanism familiar to Swift developers and we don't want to spend the entire proposal showing all various types of serializers and how they can work. We will spend much more time on how the serialization runtime actually is invoked in proposals covering the runtime aspect of distributed actors -- this proposal only explains the type-checking and configurability aspects of serialization requirements.

@bobergj

This gives me the impression that, initially, the primary use-case for this is XPC between local processes on Apple OSs. [...]
At the same time, the set of failure modes for communication between local processes is very different to communication in distributed systems over the internet . I feel like this proposal is painting a too rosy a picture [...]

Inter-process communication definitely among the use-cases for distributed actors, but it is–by far–not the only one.

You may be surprised to learn that this work originated from networking use-cases, and our experience building distributed systems using actors in other languages. We also recently open sourced a complete distributed actor system cluster (swift.org blog), and have experience with other such systems, like Akka and there's plenty other examples in the industry such as Orleans So yes, the model works well for networking, as much as it does for IPC.

You may also want to check out the talk I linked above [Video] Distributed Actors announced at Scale by the Bay since the latter section of it discusses the failure handling in a real implementation in more detail.