Understanding Elixir Processes
Elixir processes are not operating system threads or processes; they are extremely lightweight units of execution managed by the BEAM virtual machine. Each process starts with only a few kilobytes of memory, has its own isolated heap and garbage collector, and shares no memory with any other process. Because of this isolation, a running Elixir system can comfortably host hundreds of thousands or even millions of concurrent processes, all scheduled preemptively by BEAM's own scheduler across available CPU cores.
Cricket analogy: Think of a T20 franchise's net-bowling session where dozens of net bowlers train in separate nets at once, like MS Dhoni's CSK camp -- each bowler works in isolation with his own kit, so one bowler pulling a hamstring doesn't stop the other nets from running.
Spawning Processes
You create a new process with spawn/1, passing an anonymous function, or spawn/3, passing a module, function name, and argument list. The call returns immediately with a PID (process identifier) for the newly created process, while the calling process continues executing without waiting. Because each process has its own stack and heap, an unhandled exception in one spawned process terminates only that process and does not corrupt or crash the caller or any sibling process.
Cricket analogy: Sending a substitute fielder onto the ground with spawn is like a captain like Rohit Sharma calling on a specialist boundary rider -- the ground announcer confirms the change instantly (the PID) while the match clock keeps ticking without pausing for the substitution.
defmodule Greeter do
def greet(name) do
IO.puts("Hello, #{name}! (from process #{inspect(self())})")
end
end
# Spawn a process with an anonymous function
pid1 = spawn(fn -> Greeter.greet("Ada") end)
# Spawn a process with a module, function, and args
pid2 = spawn(Greeter, :greet, ["Grace"])
IO.inspect(pid1)
IO.inspect(pid2)Message Passing with send and receive
Processes cannot touch each other's memory, so the only way they cooperate is by sending immutable messages with send/2 and retrieving them inside a receive block, which pattern-matches against messages sitting in the process's mailbox in the order they arrive. If none of the receive clauses match the message at the head of the mailbox, that message stays queued and Elixir tries the next one, a behavior called selective receive that lets a process skip irrelevant messages until it's ready to handle them, optionally with an after clause for a timeout.
Cricket analogy: A team's dressing-room runner delivering a note from the coach, like during a DRS review, waits in the queue with other instructions until the batsman on strike is ready to read it, and messages he doesn't need yet just sit until relevant.
defmodule Pinger do
def loop do
receive do
{:ping, sender} ->
IO.puts("Received ping, sending pong")
send(sender, :pong)
loop()
:stop ->
IO.puts("Stopping pinger")
end
end
end
pid = spawn(Pinger, :loop, [])
send(pid, {:ping, self()})
receive do
:pong -> IO.puts("Got pong back!")
after
1000 -> IO.puts("Timed out waiting for pong")
end
send(pid, :stop)Process Identifiers (PIDs) and Naming
Every process is uniquely identified by a PID, which you obtain for the current process with self/0 or receive back as the return value of spawn. Because passing PIDs around by hand becomes unwieldy in larger systems, Elixir lets you register a process under an atom name using Process.register/2, after which other code can send messages to that name directly instead of tracking the PID, though only one process can hold a given registered name at a time.
Cricket analogy: Every player has a fixed jersey number for the tournament, like Virat Kohli's number 18, and instead of shouting a jersey number across the ground, the team just calls him 'Skipper' -- a name that always resolves to whoever currently holds that role.
BEAM schedulers use preemptive, reduction-counted scheduling: every process gets a fair time slice measured in function-call 'reductions' rather than wall-clock time, which is why a CPU-heavy process can't starve the scheduler the way a runaway thread can in many other runtimes.
- Elixir processes run on the BEAM VM, not the OS; they are cheap to create (a few KB each) and isolated from one another.
- spawn/1 and spawn/3 create a new process and immediately return its PID without blocking the caller.
- Processes share no memory; the only way to communicate is by sending messages with send/2.
- receive pattern-matches messages out of the calling process's mailbox, supporting selective receive and an after timeout clause.
- self/0 returns the PID of the currently executing process.
- Process.register/2 binds an atom name to a PID so other code can address it without tracking the raw PID.
- An unhandled crash in one process does not corrupt or halt unrelated processes, thanks to per-process heaps and isolation.
Practice what you learned
1. What is the primary difference between an Elixir process and an operating system process?
2. What does spawn/1 return?
3. How does a process retrieve messages sent to it?
4. What happens if a spawned process raises an unhandled exception?
5. What is the purpose of Process.register/2?
Was this page helpful?
You May Also Like
GenServer Explained
Understand how GenServer standardizes stateful server processes in Elixir with a clean client/callback API.
Supervisors and OTP
Learn how OTP supervisors monitor child processes and restart them automatically to build fault-tolerant systems.
Fault Tolerance in Elixir
Explore how links, monitors, and the let-it-crash philosophy combine to make Elixir systems resilient by design.
Related Reading
Related Study Notes in Programming
Browse all study notesApache Spark Study Notes
Programming · 30 topics
ProgrammingApache Flink Study Notes
Programming · 30 topics
ProgrammingHadoop Study Notes
Programming · 30 topics
ProgrammingSnowflake Study Notes
Programming · 30 topics
ProgrammingApache Airflow Study Notes
Programming · 30 topics
Programmingdbt (Data Build Tool) Study Notes
Programming · 30 topics