Paolo Laurenti (2) [Avatar] Offline
#1
Inside chapter 5.3.3 there's the following code example:

defmodule Calculator do
  def start do
    spawn(fn -> loop(0) end)
  end

  def value(server_pid) do
    send(server_pid, {:value, self})
    receive do
      {:response, value} ->
        value
    end
  end

  def add(server_pid, value), do: send(server_pid, {:add, value})
  def sub(server_pid, value), do: send(server_pid, {:sub, value})
  def mul(server_pid, value), do: send(server_pid, {:mul, value})
  def div(server_pid, value), do: send(server_pid, {:div, value})
  
  ...
end


After the example there's the following explanation:
Keep in mind that the server handles messages in the order received, so requests are handled in the proper order.

What is written is correct but I think that the "so part" after the comma could be easily misunderstood.
In fact I think that it would be better to clarify that there's no guarantee that the server will receive the messages in the same exact order they've been sent. So, in the example above, there's no absolute guarantee that the server will compute the arithmetic expression with the same order specified by the client.
sjuric (86) [Avatar] Offline
#2
Thanks for pointing it out. Looking at the passage, I see that there might be some ambiguity there, so I'll consider some slight rewording for the next edition.

However, I want to clarify this point:


there's no guarantee that the server will receive the messages in the same exact order they've been sent


From the standpoint of the single client, the server will indeed receive the message in the order in which they've been sent. For example, if the client issues the sequence of add, sub, mul, div, then you can count on server receiving the messages in that order.

The story becomes more complicated when there are multiple clients. In this case you can't predict the order of execution, so you can't reliably know the total message ordering. But it's always guaranteed that messages sent from the single client will be received in the order in which they've been sent.
Paolo Laurenti (2) [Avatar] Offline
#3
Thanks a lot for your reply and sorry if mine arrives a bit late (I was on vacation...).

You wrote:

For example, if the client issues the sequence of add, sub, mul, div, then you can count on server receiving the messages in that order.


If I understand it correctly the sorting invariant is guaranteed because the processes are running on localhost and therefore there's no network involved.
I think that the message ordering could not be guaranteed if the processes are running on different machines (e.g. a message sent first on the network could be slower the a following one).
Am I wrong? In case could you explain me why, please?

p.s. Kudos for your book, it's amazing! smilie
sjuric (86) [Avatar] Offline
#4
Paolo Laurenti wrote:Thanks a lot for your reply and sorry if mine arrives a bit late (I was on vacation...).
I think that the message ordering could not be guaranteed if the processes are running on different machines (e.g. a message sent first on the network could be slower the a following one).
Am I wrong? In case could you explain me why, please?


Two nodes communicate over a single TCP connection, and all messages are being passed through that connection. Therefore, there's no way that the second message will reach the target node before the first one.



p.s. Kudos for your book, it's amazing!


Happy to learn you like it smilie