Erlang OTP: Distributed & Fault-Tolerant Systems Programming · レッスン

リンクとモニターを理解する

リンクとモニターの違いを学び、プロセスの監視と終了シグナルの伝播におけるそれぞれの役割を理解します。

「リンクとモニターを理解する」はCoddyKit上の無料Erlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンです。これはレッスン1/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはErlang OTP: Distributed & Fault-Tolerant Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

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 error

Trapping 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.

よくある質問

「リンクとモニターを理解する」レッスンは無料ですか？

はい。「リンクとモニターを理解する」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Erlang OTP: Distributed & Fault-Tolerant Systems Programmingコースには全4レッスンが含まれています。

「リンクとモニターを理解する」で何を学びますか？

リンクとモニターの違いを学び、プロセスの監視と終了シグナルの伝播におけるそれぞれの役割を理解します。ブラウザで直接実行するハンズオンコードでErlang OTP: Distributed & Fault-Tolerant Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Erlang OTP: Distributed & Fault-Tolerant Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのErlang OTP: Distributed & Fault-Tolerant Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン1/4です。

「リンクとモニターを理解する」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのErlang OTP: Distributed & Fault-Tolerant Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Erlang OTP: Distributed & Fault-Tolerant Systems Programmingに戻る