|
|
|
|
|
|
by rdtsc
4140 days ago
|
|
|
Thank you explaining! I understand it better now. This comment would make a great doc entry. It looks like ActorRef is equivalent to Erlang's process ID's (PIDs). As there a message is sent to an actor's PID. Props sound very powerful. I like the idea. With Erlang one can do it but with extra work. With live code-reloading and access to the module loader. Do Actor hierarchies imply a global registration mechanism. If it does, wondering what kind of consistency/availability trade-offs it makes. Erlang's clusters do not handle network partitions too well sometimes and there are few custom registration/leader-election libraries for it. (locks, gproc, pg2) |
|
|
No, all registration is done locally underneath the parent actor - i.e. if one parent creates three children, the only place where that state is registered is the parent itself. The root actor on each node can quickly figure out by traversing the tree whether or not a child at a given path exists or not.
The only exception to this convention are remote-deployed actors - if ActorSystem A deploys an actor remotely onto ActorSystem B, the RemoteDaemon (a system-level actor) keeps a record of who has actors deployed onto each other. That way if ActorSystem B dies (crash, network goes down, etc...) ActorSystem A can notify all of the local actors who depended on remote-deployed actors that those actors are effectively dead.