Links and Monitors Explained
Differentiate between links and monitors, understanding their roles in process supervision and propagating exit signals.
Links and Monitors Explained is a free Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Erlang OTP: Distributed & Fault-Tolerant Systems Programming learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Introduction to Process Faults
Erlang processes are designed to be isolated. But what happens when one process crashes? How do other processes know, and how can they react?
Understanding how failures propagate is key to building fault-tolerant systems in Erlang. This lesson introduces two fundamental mechanisms: links and monitors.
Process Linking Explained
A link is a bidirectional connection between two Erlang processes. It's like holding hands: if one process goes down (exits), it sends an exit signal to all linked processes.
- Links are created with
spawn_link/1,2,3,4. - If a process linked to another process exits normally, the exit signal is
normal. - If it exits with an error, the exit signal carries the reason for the crash.
Linking: Default Crash Propagation
By default, if a process receives an exit signal (other than normal) from a linked process, it will also terminate with the same reason. This is known as crash propagation.
Try running this example. The child process crashes, and because the parent is linked, it also crashes!
-module(link_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting...~n", [ParentPid]),
ChildPid = spawn_link(fun() -> child_process(ParentPid) end),
io:format("Parent (~p) linked to child (~p).~n", [ParentPid, ChildPid]),
timer:sleep(5000), % Wait for child to crash
io:format("Parent (~p) still alive (this won't print if it crashed).~n", [ParentPid]).
child_process(ParentPid) ->
io:format("Child (~p) started, linked to Parent (~p).~n", [self(), ParentPid]),
timer:sleep(1000), % Simulate some work
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed). % Child exits with an errorTrapping Exits: Handling Failures
While crash propagation is useful for simple 'all or nothing' scenarios, often you want a process to *handle* a linked process's crash, not just die with it. This is where trapping exits comes in.
By setting process_flag(trap_exit, true), a process will convert incoming exit signals from linked processes into {'EXIT', Pid, Reason} messages, which it can then receive and process.
Trapping Exits in Code
Here, the parent process traps exits. When the child crashes, the parent receives an 'EXIT' message instead of crashing itself. This is fundamental for building supervisors!
-module(trap_exit_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting and trapping exits...~n", [ParentPid]),
process_flag(trap_exit, true),
ChildPid = spawn_link(fun() -> child_process(ParentPid) end),
io:format("Parent (~p) linked to child (~p).~n", [ParentPid, ChildPid]),
receive
{'EXIT', ChildPid, Reason} ->
io:format("Parent (~p) caught exit from child (~p) with reason: ~p~n", [ParentPid, ChildPid, Reason]);
_ ->
io:format("Parent (~p) received unexpected message.~n", [ParentPid])
after 5000 ->
io:format("Parent (~p) timed out waiting for exit message.~n", [ParentPid])
end.
child_process(ParentPid) ->
io:format("Child (~p) started, linked to Parent (~p).~n", [self(), ParentPid]),
timer:sleep(1000),
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed_trapped).Process Monitoring Explained
A monitor is a unidirectional connection. It allows one process to observe another process for its termination without affecting its own lifecycle.
- Monitors are created using
erlang:monitor(process, Pid). - If the monitored process exits, the monitoring process receives a
{'DOWN', MonitorRef, process, Pid, Reason}message. - The monitoring process does NOT crash by default, even if it doesn't trap exits.
Monitoring in Action: No Crash Propagation
In this example, the parent monitors the child. When the child crashes, the parent receives a 'DOWN' message, but the parent itself remains active and doesn't crash.
-module(monitor_example).
-export([start/0]).
start() ->
ParentPid = self(),
io:format("Parent (~p) starting...~n", [ParentPid]),
ChildPid = spawn(fun() -> child_process() end),
MonitorRef = erlang:monitor(process, ChildPid),
io:format("Parent (~p) monitoring child (~p). Monitor ref: ~p~n", [ParentPid, ChildPid, MonitorRef]),
receive
{'DOWN', MonitorRef, process, ChildPid, Reason} ->
io:format("Parent (~p) received DOWN message for child (~p) with reason: ~p~n", [ParentPid, ChildPid, Reason]);
_ ->
io:format("Parent (~p) received unexpected message.~n", [ParentPid])
after 5000 ->
io:format("Parent (~p) timed out waiting for DOWN message.~n", [ParentPid])
end,
io:format("Parent (~p) finished, still alive!~n", [ParentPid]).
child_process() ->
io:format("Child (~p) started, will crash soon.~n", [self()]),
timer:sleep(1000),
io:format("Child (~p) crashing now!~n", [self()]),
exit(i_crashed_monitored).Links vs. Monitors: Key Differences
Choosing between links and monitors depends on your fault tolerance strategy. Here's a quick comparison:
- Links: Bidirectional, default crash propagation, used for tightly coupled processes (e.g., parent-child in a supervision tree).
- Monitors: Unidirectional, send
'DOWN'messages only, no default crash propagation, used for loosely coupled processes or temporary observation. - Links are for when you want processes to 'live or die together' (unless trapping exits). Monitors are for when you just want to 'know if it died'.
When to Use Which?
Links are the foundation of Erlang's supervision trees, where a supervisor is linked to its children and traps exits to restart them. Monitors are often used for situations like checking if a remote service is still active, or for resource cleanup after a process exits.
You can also create a link using erlang:link(Pid) and remove it with erlang:unlink(Pid). Similarly, you can remove a monitor with erlang:demonitor(MonitorRef).
Question: Link or Monitor?
Imagine you are building an Erlang application. In which of the following scenarios would using a monitor be more appropriate than a link?
Recap: Links and Monitors
In this lesson, you've learned about Erlang's core fault tolerance primitives:
- Links: Bidirectional connections that propagate exit signals, causing default crash propagation.
- Trapping Exits: A mechanism for linked processes to convert exit signals into messages, allowing them to handle failures.
- Monitors: Unidirectional connections that send
'DOWN'messages upon termination of the monitored process, without default crash propagation.
These mechanisms are fundamental for building robust, self-healing Erlang applications, forming the bedrock of OTP supervision trees.
Frequently asked questions
Is the “Links and Monitors Explained” lesson free?
Yes — the full text of “Links and Monitors Explained” is free to read here on the web, and the Erlang OTP: Distributed & Fault-Tolerant Systems Programming course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Erlang OTP: Distributed & Fault-Tolerant Systems Programming course, upgrade to CoddyKit PRO.
What will I learn in “Links and Monitors Explained”?
Differentiate between links and monitors, understanding their roles in process supervision and propagating exit signals. You practise Erlang OTP: Distributed & Fault-Tolerant Systems Programming with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Erlang OTP: Distributed & Fault-Tolerant Systems Programming?
No prior experience is required. Erlang OTP: Distributed & Fault-Tolerant Systems Programming on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Links and Monitors Explained” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson?
Yes. Every Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Links and Monitors Explained
- Robust Error Handling
- Designing for Crash-First
- The Let-It-Crash Philosophy