[erlang-questions] From whence do monitors come?

[Ulf Wiger]

On 09/10/2010 03:07 PM, Matthew Sackman wrote:
> gen.erl has the following code in do_call:
> 
> 	    catch erlang:send(Process, {Label, {self(), Mref}, Request},
> 		  [noconnect]),
> 	    receive
> 		{Mref, Reply} ->
> 		    erlang:demonitor(Mref, [flush]),
> 		    {ok, Reply};
> 		{'DOWN', Mref, _, _, noconnection} ->
> 		    exit({nodedown, Node});
> 		{'DOWN', Mref, _, _, Reason} ->
> 		    exit(Reason)
> 
> If the callee is something like a gen_server, and on handling that msg
> returns a {stop, Reply, Reason, State} quple, there seems to be a race
> between the reply and the monitor. Or more simply, say the callee does
> something like:
> 
> receive {'$gen_call', From, _Msg} -> gen_server:reply(From, done) end.
> 
> There seems to be a race - what's stopping the DOWN from the monitor
> overtaking the reply from the callee?
> 
> The only thing that I can think of is that the DOWN is considered to
> come *from* the callee. Is that right?

This is the only conclusion that would be compatible with the ordering
guarantee, IMHO. The gen_server explicitly sends the reply before it
dies, and it would be almost impossible to write an efficient and
safe implementation of do_call if one couldn't be sure that the DOWN
message will never be delivered before the last message sent to the
same recipient.

The ordering guarantee should be clearly documented in the reference
manual, together with a clear statement on how EXIT signals and
DOWN messages play along with that guarantee.

BR,
Ulf W