شرح الروابط والمراقبين

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.

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.

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!

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.

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!

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.

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.

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

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

Imagine you are building an Erlang application. In which of the following scenarios would using a monitor be more appropriate than a link?

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.