Skip to content
Links, Monitors, and Supervision
step 1/5

Reading — step 1 of 5

Learn

~1 min readErrors and Supervision

Links create bidirectional crash-propagation between two processes. Monitors are unidirectional notifications.

link(Pid) / spawn_link(Fun):

spawn_link(fun() ->
    timer:sleep(100),
    exit(normal)
end).

If either process dies abnormally, the other dies too — unless it has process_flag(trap_exit, true), which converts exit signals into messages:

process_flag(trap_exit, true),
Worker = spawn_link(fun() -> error(boom) end),
receive
    {'EXIT', Worker, Reason} ->
        io:format("worker died: ~w~n", [Reason])
end.

This is how supervisors work — they trap exits and restart children.

Monitors with erlang:monitor/2:

Ref = erlang:monitor(process, Pid),
receive
    {'DOWN', Ref, process, Pid, Reason} ->
        handle_died(Pid, Reason)
end.

One-way: the monitor receives a DOWN message; the monitored process is unaffected. Useful for one-off observation without entangling lifetimes.

Supervisors are OTP behaviour modules — battle-tested, declarative process trees with restart strategies (one_for_one, one_for_all, rest_for_one). For real systems, use supervisor from OTP rather than rolling your own.

The point of all this: instead of try/catch everywhere, you isolate failures inside processes and use supervisors to restart them. A bad input crashes one worker; the supervisor restarts it; the system stays up.

This is what "nine nines" of uptime is built on — Ericsson's AXD301 ATM switch hit 99.9999999% availability using exactly these primitives.

Discussion

Ask a question, share an insight, or help someone who’s stuck.

Sign in to post a comment or reply.

Loading…