goodboy/tractor

An "actor model" eh?

goodboy opened this issue · 10 comments

goodboy commented

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?):

Reference implementations in other languages and frameworks:

goodboy commented

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

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
goodboy commented

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

goodboy commented

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 commented

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 😄
goodboy commented

Some further inside from an existing systems perspective:

goodboy commented

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

gc-ss commented

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 commented

@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 commented

The rant task is codified in #210.