venomnert
How does process treat unhandled messages?
Context:
I’m reading through “Elixir in Action” by“ Saša Jurić. In section 5.2.2 he provides the following algorithm on how processes read messages:
The receive expression works as follows:
- Take the first message from the mailbox.
- Try to match it against any of the provided patterns, going from top to bottom.
- If a pattern matches the message, run the corresponding code.
- If no pattern matches, put the message back into the mailbox at the same position it originally occupied. Then try the next message.
- If there are no more messages in the queue, wait for a new one to arrive. When a new message arrives, start from step 1, inspecting the first message in the mailbox.
- If the after clause is specified and no message is matched in the given amount of time, run the code from the after block.
Scenario:
Assume that a process receives these three message in the following order:
- message a
- message b
- message c
Here is the process receive statement:
receive do
{:message_b, value} -> IO.puts "Message b is complete"
{:message_c, value} -> IO.puts "Message c is complete"
end
Question:
Will the process always start from the top of the queue all the time, even if it already knows that it can’t handle the first message? In above case it always start off by trying to see if it can handle message_a (which it can’t) and then continue to proceed to the next message.
Marked As Solved
jwarlander
Yes, indeed it will… The result, if your process doesn’t ever flush out otherwise unhandled messages, is that it may end up sifting through millions of them just to process those that are relevant. This is something that you’ll need to be aware of; either crash on an unexpected message, or (at some point at least) throw it away.
Also Liked
al2o3cr
FWIW this behavior is one of the reasons it’s usually preferable to use structured machinery around send + receive, like gen_server and friends - unexpected messages will be converted to crashes.
sb8244
Here’s something you can run locally:
defmodule MyLoop do
def loop do
IO.puts "Entering the loop"
receive do
:msg_b ->
IO.puts "msg b"
loop.()
:msg_c ->
IO.puts "msg c"
loop.()
end
end
end
pid = spawn(&MyLoop.loop/0)
send(pid, :msg_a)
send(pid, :msg_b)
send(pid, :msg_c)
send(pid, :msg_a)
send(pid, :msg_b)
send(pid, :msg_c)
Process.info(pid, :messages)
My output:
Entering the loop
iex(17)> send(pid, :msg_a)
:msg_a
iex(18)> send(pid, :msg_b)
msg b
Entering the loop
:msg_b
iex(19)> send(pid, :msg_c)
msg c
Entering the loop
:msg_c
iex(20)> send(pid, :msg_a)
:msg_a
iex(21)> send(pid, :msg_b)
msg b
Entering the loop
:msg_b
iex(22)> send(pid, :msg_c)
msg c
:msg_c
Entering the loop
iex(26)> Process.info(pid, :messages)
{:messages, [:msg_a, :msg_a]}
You can see that msg_a will pile up in the process queue, as @jwarlander mentions
dom
If you’d like the gory details: https://blog.stenmans.org/theBeamBook/#_message_passing
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Build Elixir applications with speed and confidence.
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
Courses that'll move you from confusion to "Aha, now I get it!"