I'll caveat this with "Yep, these could be all implementation details". In starting to dig through the source for swift-distributed-actors, there are some things I knew the concepts for (basic actor concept, mailboxes, and messages). The distributed actors code steps it up a bit, and uses some terms and phrasing that I wasn't very familiar with. I could guess and infer quite a bit, but I thought it might be best to ask about the specific terms and how they're inter-related.
I started at ActorSystem, thinking that might be the "top of the tree" for the implementation details (based on its use in the Dining Philosopher's sample) and STYLE_GUIDE.md since it seemed to have a bit of glossary included within it.
From within the style guide, there's a reference to a distributed actor processing messages from its mailbox being called 'reduction' and talk about how that applies a behavior. So an Actor's behavior seems like a pretty key concept. So generally, what is a behavior, and how does it relate to actors?
From the code in Behaviors.swift, the abstract for it reads:
A
_Behavior
is what executes when anActor
handles messages.
Is a behavior something that a developer would provide, or is it more of an implementation detail of how distributed actors manages its own data models and execution? I suspect it's related - but just to verify - the 'shell' concept is for the system actors to react to messages from other distributed actors and defines some concrete ways that it handles the local ActorSystems state, is that correct? That the implementation of the local distributed system's internal actors handling messages was a 'shell'?
ActorSystem has a public method park
that calls down into a transport to do its work. What's the implication of parking an actor system - or more generally what's that intended to do? In the sample, one of the ActorSystems is parked with that looks like a deadline concept - is that implying "run as you need to for at least X amount of time?" or am I misinterpreting that? Are there other implications to "parking" an actorSystem?
The ActorSystem
has a systemProvider
and userProvider
with a TODO note to converge into a single tree (which is noted to be different from what Akka does), and elsewhere there's references to tree's of Actors. What does organizing the actors into trees enable, and is that a pattern that someone writing a distributed actor should know (and potentially replicate), or is that an internal detail of enabling 'watchdogs'/'supervisors' within the swift distributed actor world? (I'm guessing purely an internal detail, given they're both private - but I was curious about the history there.) I also noted that a few of the tests referenced an actor path string, which I suspected might be a string representation of that tree concept in order to identify a specific actor.
The Cluster
concept looks like it's a representation of the state of a set of distributed actors that are working together, exposed primarily through the ClusterSettings
- after which it does its thing according the implementations. Is that something with exposed hooks anywhere, or intended to be interacted with from a developer's implemented distributed actor? The sample was interesting in that it interrogated the various systems until it was happy with its status before continuing execution.
Scanning multiple source files, I saw several references to plugins - which looked like some (as yet unclear) places the code was explicitly written to be extended with implementation specific behavior - but I wasn't sure what was intended to be influenced with the plugins. What's the current thinking there, or is that a bit of legacy experimentation that's better left alone/ignored for now?
Last question - what's SACT
stand for? I'm guessing "Swift Actors" but wanted to ask, since its used as a fairly common prefix.