[erlang-questions] gen_server2 merge into OTP?
Ulf Wiger
ulf.wiger@REDACTED
Sat Jul 18 18:16:37 CEST 2009
Another thing that has been discussed (well, not
much, perhaps) that the reply message cannot
possibly be among the old messages, since it
contains a unique reference:
MRef = erlang:monitor(process, Pid),
Pid ! {'$gen_call', {self(),MRef}, Req},
receive
{MRef, Reply} -> Reply;
{'DOWN', MRef, _, _, Reason} ->
error(...)
after Time ->
error(timeout)
end.
(This is not exactly how it's implemented, but
in principle.)
If the compiler could be made to recognize this*,
selective receive could perhaps be made efficient
in the general case, even with huge message queues.
It would obviously only work under certain circumstances,
but so it is with many other optimizations too.
BR,
Ulf W
* The 'this' that the compiler would have to recognize
is that the receive above is the very first receive
after checking out the unique reference, and there is
no message in the receive clause that doesn't contain
this reference. Calling a remote function before entering
receive would render this impossible, for example.
Matthew Sackman wrote:
> On Sat, Jul 18, 2009 at 03:13:44PM +0100, Matthew Sackman wrote:
>> On Sat, Jul 18, 2009 at 03:53:52PM +0200, Ulf Wiger wrote:
>>> "OTP-7979 gen_server:call/2,3 will be somewhat
>>> faster if the calling process has a many
>>> messages in its message queue."
>
> It's in gen.erl, do_call/4 and wait_resp_mon/3, where if you diff, you'll
> see the older versions have additional selective receives. So
> previously, a call would result in 3 selective receives and now only 1.
> OTOH, if you have a million messages in your mailbox, a factor of 3 is
> pretty much irrelevant. Getting that mailbox empty is what's important,
> which is why gen_server2 helps, because you are not scanning the
> internal queue.
>
> Matthew
--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com
More information about the erlang-questions
mailing list