Liens et moniteurs expliqués
Distinguez les liens des moniteurs et comprenez leur rôle dans la supervision des processus et la propagation des signaux de terminaison
Liens et moniteurs expliqués est une leçon Erlang OTP: Distributed & Fault-Tolerant Systems Programming gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Erlang OTP: Distributed & Fault-Tolerant Systems Programming, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Erlang OTP: Distributed & Fault-Tolerant Systems Programming comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
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.
Questions Fréquemment Posées
La leçon « Liens et moniteurs expliqués » est-elle gratuite ?
Oui — le texte complet de « Liens et moniteurs expliqués » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Erlang OTP: Distributed & Fault-Tolerant Systems Programming, passe à CoddyKit PRO. Le cours Erlang OTP: Distributed & Fault-Tolerant Systems Programming comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Liens et moniteurs expliqués » ?
Distinguez les liens des moniteurs et comprenez leur rôle dans la supervision des processus et la propagation des signaux de terminaison Tu pratiques Erlang OTP: Distributed & Fault-Tolerant Systems Programming avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Erlang OTP: Distributed & Fault-Tolerant Systems Programming ?
Aucune expérience préalable n'est requise. Erlang OTP: Distributed & Fault-Tolerant Systems Programming sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Liens et moniteurs expliqués » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Erlang OTP: Distributed & Fault-Tolerant Systems Programming ?
Oui. Chaque leçon Erlang OTP: Distributed & Fault-Tolerant Systems Programming inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Liens et moniteurs expliqués
- Gestion robuste des erreurs
- Concevoir selon le principe « crash-first »
- La philosophie « laisser planter »