Links en monitors uitgelegd
Leer het verschil tussen links en monitors en krijg inzicht in hun rol bij processupervisie en het doorgeven van exitsignalen.
Links en monitors uitgelegd is een gratis Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen-les op CoddyKit. Dit is les 1 van 4. Je kunt 3 lessen uit dit leerpad gratis volledig lezen — daarna ontgrendelt CoddyKit PRO alle lessen, plus praktische oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Inleiding tot procesfouten
Erlang-processen zijn ontworpen om geïsoleerd te zijn. Maar wat gebeurt er wanneer een proces crasht? Hoe weten andere processen dat en hoe kunnen ze reageren?
Begrijpen hoe fouten zich verspreiden is essentieel voor het bouwen van fouttolerante systemen in Erlang. In deze les maak je kennis met twee fundamentele mechanismen: koppelingen en monitors.
Uitleg over proceskoppelingen
Een koppeling is een bidirectionele verbinding tussen twee Erlang-processen. Het is alsof je elkaars hand vasthoudt: als één proces uitvalt (wordt beëindigd), stuurt het een beëindigingssignaal naar alle gekoppelde processen.
- Koppelingen worden gemaakt met
spawn_link/1,2,3,4. - Als een proces dat aan een ander proces is gekoppeld normaal wordt beëindigd, is het beëindigingssignaal
normal. - Als het proces met een fout wordt beëindigd, bevat het beëindigingssignaal de reden voor de crash.
Koppelen: standaardverspreiding van crashes
Standaard wordt een proces dat een beëindigingssignaal (anders dan normal) ontvangt van een gekoppeld proces, ook beëindigd met dezelfde reden. Dit heet verspreiding van crashes.
Probeer dit voorbeeld uit te voeren. Het onderliggende proces crasht en omdat het bovenliggende proces ermee is gekoppeld, crasht dat ook!
-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 errorBeëindigingen onderscheppen: fouten afhandelen
Verspreiding van crashes is handig voor eenvoudige scenario's waarin alles moet slagen of mislukken, maar vaak wil je dat een proces de crash van een gekoppeld proces *afhandelt* in plaats van er gewoon samen mee te stoppen. Daarvoor kun je beëindigingen onderscheppen.
Door process_flag(trap_exit, true) in te stellen, zet een proces binnenkomende beëindigingssignalen van gekoppelde processen om in berichten van de vorm {'EXIT', Pid, Reason}. Het kan deze berichten vervolgens ontvangen en verwerken.
Beëindigingen in code onderscheppen
Hier onderschept het bovenliggende proces beëindigingen. Wanneer het onderliggende proces crasht, ontvangt het bovenliggende proces een bericht 'EXIT' in plaats van zelf te crashen. Dit is essentieel voor het bouwen van 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).Uitleg over procesmonitoring
Een monitor is een unidirectionele verbinding. Hiermee kan het ene proces een ander proces observeren om te zien wanneer het wordt beëindigd, zonder de eigen levensduur te beïnvloeden.
- Monitors worden gemaakt met
erlang:monitor(process, Pid). - Als het gemonitorde proces wordt beëindigd, ontvangt het monitorende proces een bericht
{'DOWN', MonitorRef, process, Pid, Reason}. - Het monitorende proces crasht standaard NIET, zelfs niet als het afsluitingen niet onderschept.
Monitoring in actie: geen crashdoorgifte
In dit voorbeeld monitort het ouderproces het kindproces. Wanneer het kindproces crasht, ontvangt het ouderproces een 'DOWN'-bericht, maar het ouderproces blijft zelf actief en crasht niet.
-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).Koppelingen versus monitors: belangrijkste verschillen
De keuze tussen koppelingen en monitors hangt af van je strategie voor fouttolerantie. Hier volgt een korte vergelijking:
- Koppelingen: Bidirectioneel, standaard doorgifte van crashes, gebruikt voor nauw gekoppelde processen (bijvoorbeeld ouder- en kindprocessen in een supervisieboom).
- Monitors: Unidirectioneel, versturen alleen
'DOWN'-berichten, zonder standaard doorgifte van crashes, gebruikt voor losjes gekoppelde processen of tijdelijke observatie. - Koppelingen gebruik je wanneer je wilt dat processen 'samen leven of sterven' (tenzij ze afsluitingen onderscheppen). Monitors gebruik je wanneer je alleen wilt 'weten of het is gestopt'.
Wanneer gebruik je welke?
Koppelingen vormen de basis van de supervisiebomen van Erlang, waarin een supervisor aan zijn kinderen is gekoppeld en afsluitingen onderschept om ze opnieuw te starten. Monitors worden vaak gebruikt om bijvoorbeeld te controleren of een externe service nog actief is, of om bronnen op te ruimen nadat een proces is beëindigd.
Je kunt ook een koppeling maken met erlang:link(Pid) en deze verwijderen met erlang:unlink(Pid). Op dezelfde manier kun je een monitor verwijderen met erlang:demonitor(MonitorRef).
Vraag: koppeling of monitor?
Stel dat je een Erlang-toepassing bouwt. In welke van de volgende situaties zou een monitor geschikter zijn dan een koppeling?
Samenvatting: koppelingen en monitors
In deze les heb je de belangrijkste primitieve mechanismen voor fouttolerantie in Erlang geleerd:
- Koppelingen: Bidirectionele verbindingen die afsluitsignalen doorgeven, waardoor crashes standaard worden doorgegeven.
- Afsluitingen onderscheppen: Een mechanisme waarmee gekoppelde processen afsluitsignalen omzetten in berichten, zodat ze fouten kunnen afhandelen.
- Monitors: Unidirectionele verbindingen die
'DOWN'-berichten versturen wanneer het gemonitorde proces wordt beëindigd, zonder standaard doorgifte van crashes.
Deze mechanismen zijn essentieel voor het bouwen van robuuste, zelfherstellende Erlang-toepassingen en vormen de basis van OTP-supervisiebomen.
Leer Erlang met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 12
- Lessen
- 48
Veelgestelde vragen
Is de les “Links en monitors uitgelegd” gratis?
Ja — je kunt hier op het web alle 3 lessen van het leerpad Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen, waaronder “Links en monitors uitgelegd”, gratis volledig lezen. Daarna ontgrendelt CoddyKit PRO alle lessen, plus interactieve oefeningen met een ingebouwde code-editor en een AI-tutor die 24/7 beschikbaar is. De cursus Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat in totaal 4 lessen.
Wat leer ik in “Links en monitors uitgelegd”?
Leer het verschil tussen links en monitors en krijg inzicht in hun rol bij processupervisie en het doorgeven van exitsignalen. Je oefent met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen te beginnen?
Ervaring vooraf is niet nodig. Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 1 van 4.
Hoe lang duurt de les “Links en monitors uitgelegd”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen?
Ja. Elke les over Erlang OTP: programmeren van gedistribueerde en fouttolerante systemen bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- Links en monitors uitgelegd
- Robuuste foutafhandeling
- Ontwerpen volgens het crash-first-principe
- De let-it-crash-filosofie