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