An "actor model" eh?

[goodboy]

This is a discussion thread to dig into the theory surrounding how this project is (like) an actor model system and how it is or isn't compatible with structured concurrency.

BEFORE YOU THINK OR READ ANYTHING ELSE.

Watch this vid by the original author of the theory if you think you know what an actor model is or does, or looks like: https://www.youtube.com/watch?v=7erJ1DV_Tlo

Hint: it's a computational model not an API.

A bunch of stuff that should probably be referenced in the docs and aluded to more formally in the implementation (if that's what we're after?):

• an 1985 actor model paper a follow up to the original
• the wikipedia "theory" page
• the wikipedia history page
• the descendent π-calculus

Reference implementations in other languages and frameworks:

• a microsoft paper on their orleans: distributed virtual actors framework

[goodboy]

I've noticed many opinionated pronouncements about what does and does not constitute a true actor model:

• Nathaniel's note on the nursery naming thread seems rather strict about how structured concurrency is somehow incompatible (not sure I agree) though it is true that trio tasks don't adhere to certain actor behaviour requirements
• stackof has some discussion on the differences with CSP and links to wikipedia's contrast with other models and the history with process calculi
• there seems to often be a lot of credence given to the way erlang decided to implement an actor model system, yet there are many different languages, framework implementations, and variants that exist.

After digging it seems to me that the theoretical core of an "actor model" is mostly well defined however in practise what does constitute being an actor model or system is somewhat flexible and less-stringent then many of the personal opinions on it (which seem to weigh one particular implementation or framework more when really the whole model is conceptual and implementation details are expected to vary).

Some resources to back this up include:

• the author of actor model theory, explicitly states this loose-ness in requirements for something to be considered an actor model in this video at the point here
• clarification of the 3 axioms from the same video
• This diploma thesis describes more qualitatively the axioms and how they are often implemented with erlang and scala as examples

The main distinguishing theoretical features of what constitutes adhering to the model seems to be rooted in 2 main concepts:

1. the details of how message passing is conducted
   • only one message is handled at a time
   • channels are not a requirement
   • there is no guaranteed arrival order
2. whether or not unbounded nondeterminism is something that can be implemented and subsequently how the system is designed to handle this dilemma
   • Hewitt's paper on the reincarnation of logic programming touches on this in the first few pages

[goodboy]

Another blog with some interesting posts: http://www.dalnefre.com/wp/

[goodboy]

Notes on how CSP vs. Actor systems mostly has to do with asynchronous-ness and naming: https://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_actor_model

[goodboy]

As a reminder to self, I would like to have a "formal stuff" spiel in the docs going over the comparison and supposed incompatibilities of tractor + SC. By almost all measures tractor is an actor model without having exposed some of the traditional apis/behaviour (message loops around channels, unbounded channels, names in every message) and still fulfills the core behaviors necessary for processes to be classified as "actors" (async message processing, inherent concurrency and parallelism, named based discovery, variable topology, async handshaking, async spawning, async "behaviors" used to handle each message, no assurance of message arrival order, locality, etc.).

One of the key points I'd like to make is just because we aren't enforcing "everything is an actor" (especially where it makes no sense) it doesn't mean you can't classify the system as actor based because, really each process running a trio scheduler does fulfill 99% of the properties of a traditional actor even if they don't look like it from the outside.

Some TODO:

• if there is one thing true of the actor model it is that it a very general model designed to cope with a very rare circumstance (unbounded nondeterminism) and claiming that because a system doesn't strictly adhere to all "unrequirements" it is not an actor model is likely incorrect even by the original author's requirements: that only the 3 main axioms must be adhered to.
• The discussion around unbufferred/bounded channels is probably one worth going into a bit since it's also still a subject of debate by theorists.
• An emphasis that actor models main shtick is that they're based on principles from physics and coping with unbounded in-determinism.
• A thread on the SC forums goes into a little detail on unbounded channels as well as how actors don't make sense "everywhere" (good thing the original author thinks the exact same thing); I think we should be adding to this discussion as well as opening a new one with some of the research from here.
• Note how CSP isn't really all that similar to tractor behavior and really the main difference between CSP and actors is the explicit requirement of channels which an actor model only rejects (as part of the core model) due to the "unnecessary overhead" that brings.
• Mention that structured concurrent processes (aka SCP) leading to trocesses sounds terrible :smile:

[goodboy]

Some further inside from an existing systems perspective:

• the supervisory policies and/or design in akka which IMO looks exactly like SC especially when you dig into what behaviors are described as. If you don't think a coroutine in python suffices as an "actor" or behavior which provides a function on each resume to handle the next "msg", I think we have something disagree on. Taking this further to our tractor "actors" - each process is able to respond, in an single threaded manner, to each new message that arrives by loading the appropriate trio "task" to handle that message. This has nothing to do with SC which has to do with the lifetime and supervisory policies around these underlying "actor" abstractions.
• the gerbil scheme runtime has an RPC system that looks eirily similar to our IAC protocol.

[goodboy]

rando link from @salotz on The wide world of almost-actors: comparing the Pony to BEAM languages: https://www.youtube.com/watch?v=_0m0_qtfzLs&t=1s

[goodboy]

cute summary: https://gist.github.com/rbishop/9082539

[gc-ss]

I think it's important to note (from the video) that messages have:

• no guaranteed arrival order,
• cannot get lost and
• can arrive atmost once although they can arrive after a large time

The atmost once could be pretty complex to implement as it's easier to sent messages multiple times than atmost once - because then you could loose/drop messages

[goodboy]

@gc-ss

no guaranteed arrival order

this is incompatible with TCP

cannot get lost and

this is incompatible with the notion of UND in real systems

can arrive atmost once although they can arrive after a large time

Also incompat with TCP retransmission afaik.

I'm not sure any of those are strict requirements. Maybe you can point to where you think that is asserted?

[goodboy]

The rant task is codified in #210.