Alright, the actual use-case here is far too cursed to explain, but I wanted to call Process.exit/2 on a remote registered name. For a local registered name I can use Process.whereis/1 to get the pid and then send it the exit signal, but there is no whereis({name, node}) function as far as I can tell.
The send/2 function accepts the pid or {name, node} tuple directly, which makes me think what actually happens is that Erlang sends the message directly to the node to be resolved in one round-trip, which makes sense. I assume that’s also why send({name, node}) cannot raise while send(name) raises for an unregistered name (which is inconsistent with the rest of OTP and kinda bizarre).
But then exit/2 does not accept {name, node} tuples, so there’s no way to send an exit signal across the network without a remote pid. But I can’t find any way to resolve a remote name to a pid!
GenServer.whereis({name, node}) literally just returns {name, node}, which again makes sense because why would you want to eat a round-trip resolving the name.
This seems like a bit of a weird hole in OTP. I guess sending exit signals to registered processes through distribution just never comes up in practice?
To be clear I am not really looking for a solution here, this is not a serious problem. I’m just wondering if anyone knows of a “blessed” way to kill a process on another node by name. You know, for science 
You could probably (e)rpc the job of sending the exit signal to the node.
2 Likes
Oh yes definitely, there are of course a bunch of ways to do this through indirection. I was just wondering if there is anything in OTP which is elegantly transparent to distribution (like so much of OTP is) and was somewhat disappointed to be unable to find a good solution.
My use case here is super weird, I’m doing fault injection testing against distributed code and I have reimplemented a good chunk of OTP in Elixir in order to enforce deterministic execution. I’ll post more about it later, it’s way too much to get into.
But I just happened to have some code which worked quite elegantly in a local/distributed fashion right up until I introduced {name, node} tuples for some processes and then I couldn’t find any way to make it work.
I’ll just go with another approach
With some caveats, the canonical way to do this in a fully connected Erlang cluster is to use global, register your process with {global, <name>} and use global:whereis_name/1.
2 Likes
They’re not quite the same, though. Maybe it’s a bit superstitious but I don’t trust :global at all, the docs don’t really explain its guarantees very well and it makes me uncomfortable. The behavior of {name, node} is extremely clear and easy to understand. Since the process is supervised and registered on a single node you can never have any weird network problems or races, plus I think bugs in the implementation are far less likely since registration is such a hot path for BEAM apps.
In my case the nodes in question actually form a VSR consensus cluster and I need everything to be as predictable and testable as possible, so this stuff actually does matter a lot. Registering a name on each node feels much safer in my case, though I’m sure there are many cases where :global is perfectly fine. It just terrifies me tbh.
But anyway, I just thought it was odd you can send({name, node}) but you can’t exit({name, node}) or even look up the pid. I guess it’s just something nobody ever does
