Yes, but that doesn’t mean that a caller has to wait for a result.
kaa.python
NobbZ
Of course it does. The caller of GenServer.call, has to wait for a result at least as long as the timeout specifies.
0
kaa.python
NobbZ
Please explain me, why you think that the caller does not need to wait for a result, GenServer.call is a synchronous operation.
0
alexandrubagu
If you don’t want the caller to wait you can use GenServer.cast, create async requests and when you want interrogate GenServer
0
NobbZ
OvermindDL1
Neither does call technically. ^.^
The GenServer call is just a GenServer cast with a receive for the result immediately after it (and a different ID atom of course). 
1
NobbZ
Due to the fact, that it is documented for cast that it might happen that the GenServer doesn’t receive the message, but it is not documented for a call, I have to assume, that we have the guarantee in a call…
1
OvermindDL1
Documentation should be fixed then. ^.^
Doing a GenServer.call is like doing:
ref = GenServer.cast(blah blah blah)
receive do
{:special, :cast, :response, ^ref, result} -> result
after 5000 -> raise puke
end
And so forth. It can entirely fail, and that is why the timeout exists too, not just if the remote process does not return in time, but if something else happened, like the GenServer crashed before you could send the cast to it, or if it is on another node that just had a netsplit.
You can never assume that a message absolutely positively will always reach its intended process, just the way reality works and so the BEAM handles it via timeouts and monitors and other links and other measures unlike almost every other language that just prays it works and dies horribly when it does not.
1