Discussion of previous to-be-removed internals of the distributed runtime
I'll put this discussion into a "spoiler" block, because none of this really matters for where we're going with the distributed actor feature, and all the mentioned types and things you asked about are either internal, private or _Underscored and to be removed.
Appendix: "Discussion of existing, to-be-removed distributed actor runtime *internals*:
You're right that this is the "top" type. In the distributed actor proposals we call this the ActorTransport but I think the name will make a comeback, because "transport" was very confusing to some reviewers, because it is more than that.
In upcoming swift evolution proposals I believe we'll rename the protocol ActorTransport to protocol DistributedActorSystem. The library's ActorSystem is an implementation of this protocol (from the _Distributed library in Swift).
Behaviors originate from the original definitions of actors in literature. In literature, an actor can only do three things:
- create more actors
- send messages
- change its behavior in reaction to an incoming message
The "change its behavior" in Swift Actors is simply this:
actor Counter {
var counter: Int = 0
func add() -> Int {
counter += 1
return counter
}
}
It means that the actor is stateful.
The behavior model takes this very explicitly, and you literarily "become a new behavior" every time you receive a message:
func behavior(counter: Int) -> _Behavior<Message> {
_Behavior.receiveMessage { message in
// for every message we receive, we just add 1 to the counter and become that behavior
return behavior(counter: counter + 1)
}
}
So behavior actors are strictly state machines, while swift actors are more normal reference types where you just modify your state in the instance, and that is the "behavior change". Behaviors are pretty powerful in how they can be composed, but that's a whole different topic. You can imagine having a "door actor" that becomes a "closed behavior", rejecting attempts to close it, and then becoming the "open behavior" -- this is like swapping the implementation of functions in a Swift Actor, which we can't do, but instead would model it by doing a switch self.state { case .closed: ... case .open: ... } so we're able to express the same things, but the behavior model was really pushing you towards "think in state machines", though it becomes pretty verbose pretty quickly.
You're right that we have a few "shells"; they are just a pattern though, compensating for lacking language features (which we have solved now, thanks to distributed actor 
).
You'll notice that behaviors must define a message type they work with. Usually this is some enum like this:
enum Message {
case add(Int)
case getStatus(replyTo: ...) // since it's messages, we can't just "return from a func"
}
and the actor is implemented in terms of receiving messages... so we need to write code like this:
.receive { message in
switch message {
case .add(let amount): <something>.add(amount: amount)
case .getStatus(let replyTo): replyTo.tell(<something>.getStatus())
}
so that logic has to be somewhere... and as you can see it's pretty boring "make messages into function calls". But, thankfully this is what actors built into the language already do for us! Instead of phrasing everything as such switch, we can "just call add(amount:)"!
The "...Shell" concept is the type that contains the actor behavior and the that it delegates the calls into. It really is mostly boilerplate and compensating for the lack of actor isolation in a library only model.
All this is unnecessary now thanks to the introduction of actor and distributed actor and actor isolation in the language!
We just have not yet gotten around rewriting the big complex actors into this new world, since we're missing a few language features still.
Summing up:
| lib. only / old |
language integrated actors |
_Behavior, to hold dispatch logic |
logic inside func in an actor |
_ActorRef<Message>, to hide state from outside callers to enable thread safety |
normal variables storing an actor; actor-isolation enforces thread safety |
There's a few more concepts but generally, the theme is that all kinds of "type dance" was necessary to hide and protect state from unsafe concurrent access, while now we're able to rely on the compiler to do this for us on actor types instead
Parking the system is very "boring" and basically just blocks the calling thread until the system has been shutdown(). It is a way to write code like:
main () ... {
let system = ...
// kick off many actors
// eventually call shutdown()
try system.park()
// ok, system it shutdown, proceed with shutting down the entire process
}
Needless to say, this should go away entirely because we have both async await and this would not become await system.park().
Kind of, though not actors but nodes. You'll notice the Cluster is basically a special actor that handles all the other nodes connecting, disconnecting, ensuring we have connections alive and can talk to all other actors. It powers the system.cluster.events eventstream which provides you with events like joining/up/down about other nodes.
This piece of the design will remain unchanged in the distributed actor world. We offer the ClusterControl type which you can issue commands to, like cluster.join(<some node>) etc. So it is the type allowing end users to interact with the cluster directly on a "node level" rather than specific actors (which the receptionist is for).
We have one "plugin": the ActorSingletonPlugin. Plugins are something that starts as the system starts, and automatically can do some tasks.
The actor singleton is able to best-effort (long story about the details which we'll document) guarantee a single instance of a specific actor type is run in the entire cluster. If the node hosting the singleton dies, it is started on a different node, and other nodes automatically realize that the singleton is now hosted in a different location.
Plugins in general are just "start during system startup" and "stop during system shutdown". I'm not sure we'll need these anymore as we move towards the distributed actor world, we'll see.
Yes, Swift Actors -- we just needed some nice protocol name to use for our identities, and so sact:// was born. There isn't much meaning to it other than "our custom wire protocol that we use for the actor messaging, and wanted to have some short name for it." sdact:// didn't sound so nice 
Actor identities in the distributed actor system are URI like "addresses" and therefore they also include the protocol over which they are exposed; in this case, they're all communicating our custom cluster protocol (not stable yet), and we just called it "sact", not much more to read into it. If people wanted to use a similar identity scheme you could imagine ws:// or https:// identified actors, so it's the same idea.
Hope this answers your questions!
But at the same time, don't worry too much about these, the focus truly should be on distributed actor and the ActorSystem being an implementation of a transport / distributed actor system.
