The two sets of docs disagree about a call that timed out. The gen_server reference says that since OTP 24 calls go through a process alias, so a reply that arrives after the timeout is never received. The GenServer.call/3 page in the Elixir docs still tells you to discard late two-element tuples after catching the exit. Both sit on the same VM and the same gen module. I read the Elixir paragraph as left over. Either way the server still did the work, and neither page puts that up front.
The Erlang and Elixir docs disagree about late call replies
后续讨论 3
I love a docs mismatch. It's the easiest kind of fix to argue for. I'd keep half of that Elixir paragraph, though. The advice about discarding garbage tuples is stale for
GenServer.callon a current OTP. The useful part is the sentence before it, that the caller exits while the server may still be working. Aliases don't change that at all.So a two-part rule for the docs. Drop the garbage-message advice for the call itself. Keep the bit about the server finishing anyway, and probably expand it, because a doctest showing
{:ok, 1}will never tell anyone.The catching is the part I'd look at harder. Code that catches the timeout exit usually does it to retry. The first request is still in the server's queue or already running, so the retry runs the same operation a second time. The alias hides the first reply, and the first effect has happened anyway.
If the operation only reads, fine. If it writes, the retry needs a request identity the server can check, or the caller should let the exit happen instead of retrying.
On a current OTP the Erlang text is the one to trust. A server sleeps longer than the call allows and then replies. The caller wraps
GenServer.callincatch :exit, _and then runsflush(). Nothing. The late reply never shows up.patchkit's order is the one that costs something. Send a second call right after catching the first, and the server handles the first request to the end, then the second, so both side effects happen.
同一个问题的其他角度
Workers stuck on the results send after the context is canceled
Ran into a simple thing and spent longer on it than I'd like. A pool of eight workers reads tasks from jobs and writes result…
Eight queue slots can still leave 88 goroutines waiting
A buffered channel bounds the jobs sitting in it. It does nothing about the goroutines blocked trying to send. Say a server g…
Marking the filter async did nothing for the freeze
Search filters a list of around forty thousand rows, and the UI freezes for a moment on every query. I figured async was the…
