Process.resolve/1 which resolves any process reference to pid

Chat & Discussions Proposals: Ideas
,
1

Process.resolve/1

What it does

Takes any possible name of the process and returns a pid of the process or port (or nil if none found). Similar to Process.whereis, but this one can also handle via tuples (like {:via, Registry, {MyApp.Registry, "agent"}}) and global names (like {:global, term}).

So the spec will be @spec resolve(GenServer.name()) :: pid() | nil

This function will raise if the via-tuple callback fails, :global fails or if the node from {node, name} is unavailable.

In other words

  • pid is returned if there is a pid associated with the name
  • nil is returned when there’s no process associated with the name
  • error is raised if the pid can’t be resolved for some reason

It goes without saying that all these statements are true only at the moment of the Process.resolve/1 call

But wait, what about GenServer.whereis/1?

Process.resolve will be extremely similar to GenServer.whereis but with a single difference, so that it returns pid even when called with {name, node} tuple. Plus Process.resolve will be a less confusing name, more on this later.

Example

# With register
iex> self()
#PID<0.100.0>
iex> Process.register(self(), :iex)
iex> Process.whereis(:iex)
#PID<0.100.0>
iex> Process.resolve(:iex)
#PID<0.100.0>

# With via-tuples
iex> {:ok, _} = Registry.start_link(keys: :unique, name: MyApp.Registry)
iex> name = {:via, Registry, {MyApp.Registry, "agent"}}
iex> Agent.start_link(fn -> 0 end, name: name)
{:ok, #PID<0.123.0>}
iex> Process.resolve(name)
#PID<0.123.0>

Why

  1. This would give a clear indication that this function must be used to resolve any process name to pid. Right now, there are some libraries which were written without via-tuples in mind, but which support atom names and {:global, term} tuples and pids as arguments.
  2. Because it is handy. In many projects I worked in, I wrote this boilerplate and I can see this boilerplate of different quality implemented in libraries.
  3. It is not associated with GenServers like GenServer.whereis. The problem with GenServer.whereis is that the name can resolve to any process or even port, not a genserver, therefore it is confusing

Why resolve?

It indicates that there is some resolution (like some process, sequence of actions) happens and this function may not return and may fail, because via-tuples are basically callbacks and resolution of {node, name} tuple is an rpc call.

Implementation

It is fairly easy to implement and I can do this if this proposal gets a green light

Your comments are welcome! :smiley: