Processus Elixir et transmission de messages

Elixir is built for concurrency, and processes are its core building blocks. Think of them as tiny, isolated programs running simultaneously.

Unlike operating system processes or threads, Elixir processes are incredibly lightweight. You can have hundreds of thousands, even millions, running on a single machine!

• Isolation: Each process has its own memory.
• Communication: They talk to each other by sending messages.
• Fault Tolerance: If one crashes, it doesn't bring down others.

We create a new Elixir process using the spawn function. It takes a function (often an anonymous function) that the new process will execute.

spawn returns a Process Identifier (PID), which is like an address for the new process.

A Process Identifier, or PID, is a unique reference to an Elixir process. It's how you address a specific process to send it messages.

Think of a PID like a phone number for a person. You dial their number to talk to them, and processes use PIDs to communicate.

• Every process has a unique PID.
• PIDs are essential for message passing.
• You can inspect a PID to see its internal representation.

Just like you can get the PID of a newly spawned process, any running process can find its own PID using the self() function.

This is crucial when a process needs to tell others how to send messages back to it.

Elixir processes communicate by sending and receiving messages. This is the core of the 'share nothing' concurrency model.

Messages are simple Elixir terms (any data type) sent from one process to another's "mailbox."

• send(pid, message): Puts message into the mailbox of the process identified by pid.
• receive do ... end: Waits for messages in the current process's mailbox.

Let's see how a "client" process can send a message to a "server" process and receive a reply.

The server process uses a receive block to wait for and handle incoming messages. It then sends a reply back to the client's PID.

Elixir processes embody the 'share nothing' principle. This means processes do not share memory or state directly.

Instead, they communicate exclusively through message passing. This design choice offers significant benefits:

• Isolation: Prevents one process from corrupting another's data.
• Concurrency: Easier to reason about and scale across multiple CPU cores.
• Fault Tolerance: A crash in one process doesn't affect others, making systems more robust.

The receive block is incredibly powerful because it uses Elixir's pattern matching.

You can define different clauses within receive to match specific message structures, ignoring others until a match is found.

Since processes don't share memory, how do they maintain state? Through recursion!

A process passes its current state as an argument to itself when it calls its loop function again. This creates an immutable, sequential flow of state changes.

Consider the following Elixir code snippet:

defmodule Quiz do
  def server_loop do
    receive do
      {:ping, client_pid} ->
        send(client_pid, :pong)
        server_loop()
    end
  end

  def client_action(server_pid) do
    send(server_pid, {:ping, self()})
    receive do
      :pong ->
        IO.puts "Received pong!"
      _ ->
        IO.puts "Received something else."
    end
  end

  def run do
    server_pid = spawn(Quiz, :server_loop, [])
    client_action(server_pid)
  end
end

Quiz.run()

What will be printed to the console when Quiz.run() is executed?

Congratulations! You've taken a big step into Elixir's powerful concurrency model.

Here's a quick summary of what we covered:

• Elixir Processes: Lightweight, isolated execution units.
• PIDs: Unique identifiers for processes, used for addressing.
• spawn & self(): Functions to create processes and get their PIDs.
• Message Passing: The primary way processes communicate using send and receive.
• 'Share Nothing': Processes don't share memory, leading to robust and scalable systems.
• Pattern Matching: Used within receive to handle different message types.
• State: Maintained through recursive function calls.

These fundamental concepts are the bedrock for building highly concurrent and fault-tolerant applications in Elixir!