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:

  1. Take the first message from the mailbox.
  2. Try to match it against any of the provided patterns, going from top to bottom.
  3. If a pattern matches the message, run the corresponding code.
  4. If no pattern matches, put the message back into the mailbox at the same position it originally occupied. Then try the next message.
  5. 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.
  6. 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.

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

3 Likes

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.

3 Likes

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.

5 Likes

If you’d like the gory details: https://blog.stenmans.org/theBeamBook/#_message_passing

3 Likes