4 ms·
I'll attempt a tl;dr of this project: Carl Hewitt's actor model (often seen in Erlang, Akka & co.) uses message-passing to communicate between concurrent actor
by sph 2y ago
I'll attempt a tl;dr of this project:
Carl Hewitt's actor model (often seen in Erlang, Akka & co.) uses message-passing to communicate between concurrent actors, but doesn't easily allow for state synchronization or dynamic topologies of actors.
Tuple Spaces [https://en.m.wikipedia.org/wiki/Tuple_space https://en.m.wikipedia.org/wiki/Tuple_space] are another paradigm for distributed communication where message tuples are stored into distributed shared "space" and processes can pull messages that match a certain pattern. Very much like how biological cell communicate between each other, which allows for dynamic topologies, but you lose any concept of ordering (message X came before message Y)
The Syndicated Actor model is an attempt at bridging the two ideas to dynamically allow neighbouring actors to coordinate and communicate with each other using something like pub/sub.
---
The history page is very much worth reading: https://syndicate-lang.org/about/history/ https://syndicate-lang.org/about/history/
Here's the author's doctoral thesis: https://syndicate-lang.org/papers/conversational-concurrency-201712310922.pdf https://syndicate-lang.org/papers/conversational-concurrency...
And SYNIT, a reactive layer for Linux which aims to replace most user-space subsystems with this model: https://synit.org/book/ https://synit.org/book/
- pyinstallwoes 2y agoI tried to understand Tuple Space a few times but I don't get it. I understand Erlang and the actor model and how distributed processes work, but what is unique in the Tuple Space aspect? I vaguely recall getting it but it doesn't register for me now. Maybe it's because Erlang already has pub/sub for every 'thing?'
- sph 2y agoIn Erlang you have a PID and send messages directly to it. The topology is a directed graph. Process in a tuple space just communicate through shared memory. Messages have no address. And processes can write or pattern match messages from this shared memory space. Process A: put({"foo", "bar", 123}) put({"foo", "quux", 456}) Process B, later: get({"foo", ?x, 123}) # here x = "bar" Imagine a cell communicating with others by squirting out molecules meant for no one in particular, and having external receptors to match specific other molecules. This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.
- pyinstallwoes 2y agoSo like an implicit global mnesia accessed by "tuples" / some identity?
- layer8 2y agoThis sounds like you effectively have a global schema (in the DB sense) that all actors have to be consistent with, causing everything to be coupled with everything.
- chuckadams 2y agoThey’re coupled only as far as agreeing on a message format constitutes coupling, which is something you have to do in any actor system anyway. Bigger issue is that tuplespaces tend to be centralized, so it is very much like an app listening to table events in a db, but without a predefined schema. It’s more like pub/sub except one subscribes by message structure, not channel identity.
- layer8 2y agoYou also have to prevent unrelated actors from choosing overlapping (conflicting) message formats. In other words, you can’t decide on a new message format without knowledge of all already existing message formats.
- convolvatron 2y agoor you can just use namespaces
- layer8 2y agoThis would seem to counter “This allows actors that have not been designed to work with each other to communicate, just by sharing the same tuple space.” Alternatively, I don’t see the big difference to just using separate message queues with pattern-based retrieval. In the end, you always have to design who communicates with who in which format.
- svieira 2y agoThe author also directly relates this to Datalog and its descendants, so if you like Peter Alvaro's work this may be worth looking into more > State management via dataspaces is directly comparable to a distributed datalog-based system, and enjoys many of the same benefits. https://syndicate-lang.org/about/syndicate-in-context/ https://syndicate-lang.org/about/syndicate-in-context/
- deleted 2y ago[deleted]
- hosh 2y agoThis sounds awfully similar to Scoped Propogators. https://news.ycombinator.com/item?id=40916193 https://news.ycombinator.com/item?id=40916193
- sph 2y agoSorry, they are not at all the same thing, though I have been entertaining the idea of building a propagator with this model.
- tonyg 2y agoYay! I'm currently working on this (slowly, among many other things). Come visit #syndicate on libera.chat, if you would like to chat about this stuff!
- sph 2y agoCertainly, as soon as I'm finished reading your dissertation. I've been researching this problem for a while now and it seems you have been a few steps ahead of me all along :)
- hosh 2y agoDoes that mean that, propogators can be implemented with the primitives fescribed in syndicated actors, but not the converse?