5 ms·
Not only that, but you need a full BEAM-compatible VM, as you can send entire processes across nodes.
by sph 2y ago
Not only that, but you need a full BEAM-compatible VM, as you can send entire processes across nodes.
- throwawaymaths 2y agoNo, there are cnodes.
- snowboarder63 2y agoI actually have a side project doing this. I mapped an actor Id in ractor to a PID in erlang and used a rust create to implement the network protocol for erlang. I ran out of time on this side project kind of deal but it's like 90% there and can do a full cluster join and send and receive messages between remote actors on nodes. The crate that helped this is erl_dist. I'd love to open source the code at some point, but it's not quite there yet
- derefr 2y agoNo you can't. The closest you could get to this would be: 1. assuming a running process pA on nodeA, registered in a cluster-level process registry by name N; 2. send the process pA's state to a function on node B, which will use it to start a process pB on node B that is a clone of pA; 3. update the cluster-level process registry to point N at pB. 4. if you want to be really clever — tail-call (or code-upgrade) pA out of its existing loop, into code that makes pA act as a proxy for pB, so that anything sending a message to pA ends up talking to pB through pA. But this isn't "sending a process"; pA itself remains "stuck" on nodeA (node IDs are actually embedded in PIDs!), and there's especially no native mechanism that would do things like rewrite the links/monitors on other processes that currently point to pA, to instead point to pB (so if pA was a supervisor, you couldn't "re-parent" the children of pA over to pB.)