Process registry

As explained in Elixir in Action, Third Edition

A process registry is a component that associates application-defined names or keys with process identifiers for registration and lookup.

A process registry maps application-defined keys to process identifiers. It gives clients a stable discovery point instead of requiring them to retain a worker PID that may change after a supervisor restarts the worker. section 9.1.2

A local registry supports a practical communication workflow:

• Start the registry as a supervised process and choose a registry name plus unique or duplicate key semantics. section 9.1.2 section 9.1.4
• Register each worker under an arbitrary term such as {:database_worker, 1}, usually during initialization. section 9.1.2
• Look up the key to obtain the current PID, then send a message or make a GenServer call. section 9.1.2 section 9.1.3
• Start the registry before dependent workers, because supervisor child processes start synchronously in specification order. section 9.1.4

Elixir’s Registry accepts arbitrary complex keys, unlike ordinary local registration, which is limited to atoms. A via tuple connects those keys to OTP APIs: GenServer resolves the registry entry when starting, calling, or casting to a process. section 9.1.2 section 9.1.3

Registering supervised database workers

Define a small registry wrapper with start_link/0, via_tuple/1, and child_spec/1. Start it before the database workers. Each worker receives a {db_folder, worker_id} argument and starts with name: via_tuple(worker_id). Client functions can then call GenServer.cast or GenServer.call with the same registry-backed name rather than a stored PID. section 9.1.4

Figure 9.3 Discovering processes through a registry

Use the process-discovery diagram to trace registration, lookup, and message delivery across worker restarts. section 9.1.2

The abstraction remains local to one node. Cluster-wide discovery requires another mechanism, such as Erlang’s :global for one registered process or :pg for groups of processes. section 12.1.3

How Elixir in Action, Third Edition covers it

How deep it goes

Explains configuration, registration, lookup, via tuples, supervision order, and local-node scope, while deferring cluster-wide discovery to other mechanisms.

Examples

Uses database-worker pools, dynamically registered to-do servers, an EchoServer, and a SimpleRegistry implementation exercise.

What it assumes

Assumes familiarity with processes, PIDs, GenServer, and supervisors while deriving registry behavior through runnable Elixir examples.

What you can do after

Apply it via Registry and GenServer to locate supervised processes without retaining restart-sensitive PIDs.

How it connects

Connects process discovery with GenServer, OTP supervision, via tuples, ETS, distributed systems, global registration, and process groups.

liveBookmanning.com

Read Elixir in Action, Third Edition on liveBook Get the book at manning.com

Related concepts

• local process namecontrasts with · A local process name is an atom-based name for a process whose meaning is limited to the currently running BEAM instance.
• via tupleused by · A via tuple is a three-element tuple that connects an OTP process name to a custom process registry and its registry-specific lookup data.
• ETS tableuses · An ETS table is a mutable in-memory table implemented by the Erlang runtime for storing Erlang terms that can be accessed by multiple BEAM processes.
• GenServeruses · GenServer is an Erlang/Elixir OTP behavior that provides a generic callback-based implementation for stateful server processes.
• global registrationincludes · Global registration is the association of a process with a name that is visible and resolvable across all nodes in a cluster.

This explainer was generated by Manning's knowledge graph from the text of Elixir in Action, Third Edition. The section links point to the parts of the book it draws on.