[erlang-questions] performance vs msg queue length

[David Mercer]

On Monday, April 19, 2010, Ulf Wiger wrote:

> Are you sure that the work generated by a message doesn't lead to
> e.g. gen_server calls to other processes. Any such call would lead
> to a selective receive operation, which would have to scan the
> message queue.
> 
> We happened to be discussing this at the SF Erlang Factory (Patrik,
> here's your reminder): in a case such as
> 
> call(P, Req) ->
>    MRef = erlang:monitor(process, P),
>    % Mark
>    P ! {'$call', {self(),MRef}, Req},
>    receive
>       {MRef, Reply} -> Reply;
>       {'DOWN', MRef, _, _, Reason} -> erlang:error(Reason)
>    after 5000 ->
>       erlang:error(timeout)
>    end.
> 
> the compiler could figure out that it could skip to the
> end of the message queue (the end as of % Mark above),
> since the following receive clause cannot possibly match any
> messages that came in before this point (they all match on
> MRef which is a new and unique object).

Does that handle all the OTP selective receives (e.g., gen_server, mnesia,
etc.)?  That is, do all OTP selective receives follow a call to
erlang:monitor/2 and then receive matching on MRef in the same function?

Am thinking that, if so, the rule could be made implicit regarding selective
receives following erlang:monitor's in the same function.  Otherwise, a more
explicit approach might be necessary.  Some sort of mark_queue function,
which returns a reference which can then be inserted into a receive call --
something like:

	Qmark = erlang:mark_queue(),
	receive from Qmark
		. . .

Cheers,

DBM