5 ms·

I 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 uniqu

I 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 ago
In 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 ago
  So like an implicit global mnesia accessed by "tuples" / some identity?
- layer8 2y ago
  This 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 ago
    They’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 ago
      You 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 ago
        or you can just use namespaces
        layer8 2y ago
        This 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.
        tonyg 2y ago
        Absolutely. A message queue with pattern-based retrieval is a hacky way of getting the first two-thirds of a tuplespace. But, like using a database as a message queue, while it kinda sorta works for the most part, the benefits of the model come in when you start to treat it on its own terms rather than via an encoding. Tuplespaces have a little more to them (not a lot, but some) than just pattern-based retrieval, but some of the research work on them has been focused on appropriate fault-recovery strategies, strategies for sharding and distributing the spaces, etc etc.
        tonyg 2y ago
        The Syndicated Actor Model started off (see dissertation) without any notion of object or actor or entity reference at all. Actors inhabited a single dataspace and there was no baked-in addressing. Since then various developments have led to introduction of entity references (like object references in E). Taken together with dataspaces, this gives you several ways of introducing spacelike separation: you can use different message shapes+patterns, like in "classic" Syndicate or like in tuplespaces; you can use entity-references to have multiple dataspaces on the go at once, forcing isolation that way; or some combination of the two.

sph 2y ago

In 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 ago
So like an implicit global mnesia accessed by "tuples" / some identity?
layer8 2y ago
This 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 ago
  They’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 ago
    You 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 ago
      or you can just use namespaces
      - layer8 2y ago
        This 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.
        tonyg 2y ago
        Absolutely. A message queue with pattern-based retrieval is a hacky way of getting the first two-thirds of a tuplespace. But, like using a database as a message queue, while it kinda sorta works for the most part, the benefits of the model come in when you start to treat it on its own terms rather than via an encoding. Tuplespaces have a little more to them (not a lot, but some) than just pattern-based retrieval, but some of the research work on them has been focused on appropriate fault-recovery strategies, strategies for sharding and distributing the spaces, etc etc.
        tonyg 2y ago
        The Syndicated Actor Model started off (see dissertation) without any notion of object or actor or entity reference at all. Actors inhabited a single dataspace and there was no baked-in addressing. Since then various developments have led to introduction of entity references (like object references in E). Taken together with dataspaces, this gives you several ways of introducing spacelike separation: you can use different message shapes+patterns, like in "classic" Syndicate or like in tuplespaces; you can use entity-references to have multiple dataspaces on the go at once, forcing isolation that way; or some combination of the two.