[erlang-questions] gen_server2 merge into OTP?

[Paul Fisher]

Was wondering if there was any possibility that the gen_server2 [1]
would have any chance of being merged into the standard OTP
distribution? A good summary of the benefits can be found at [2].

[1]
http://hg.rabbitmq.com/rabbitmq-server/file/b95f2fd4e3f6/src/gen_server2.erl
[2] http://www.joeandmotorboat.com/2009/02/06/new-stuff-for-merle/

--
paul

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

[Ulf Wiger]

Hmm, there was a question on the list just recently which
touched on how erl_eval drains the messages and resends
them to itself, and how this severely punishes code where
selective receive is /not/ used.

BR,
Ulf W

--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

[Matthew Sackman]

On Sat, Jul 18, 2009 at 10:44:35AM +0200, Ulf Wiger wrote:
> Hmm, there was a question on the list just recently which
> touched on how erl_eval drains the messages and resends
> them to itself, and how this severely punishes code where
> selective receive is /not/ used.

The purpose of gen_server2 is a) to allow message priorities to be used;
b) to make sure that when you do a call to another process, you don't
risk having to scan a huge mailbox when the reply comes back because the
mailbox is always kept small as it's constantly drained into our own
priority queue.

If you want to see an even funkier version of gen_server2, try
http://hg.rabbitmq.com/rabbitmq-server/file/dc753bc0c54e/src/gen_server2.erl
;)

Matthew

[Ulf Wiger]

Matthew Sackman wrote:
>
> The purpose of gen_server2 is a) to allow message priorities to be used;
> b) to make sure that when you do a call to another process, you don't
> risk having to scan a huge mailbox when the reply comes back because the
> mailbox is always kept small as it's constantly drained into our own
> priority queue.

Perhaps this would be a good time for someone well
versed in the implementation to expand on exactly
what's behind this:

"OTP-7979 gen_server:call/2,3 will be somewhat
faster if the calling process has a many
messages in its message queue."

(From the OTP R13B01 release notes.)

I've browsed the sources to some extent, but it's
not obvious where this optimization is done or what
it entails.

BR,
Ulf W

--
Ulf Wiger
CTO, Erlang Training & Consulting Ltd
http://www.erlang-consulting.com

________________________________________________________________

[Matthew Sackman]

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."
>
> (From the OTP R13B01 release notes.)
>
> I've browsed the sources to some extent, but it's
> not obvious where this optimization is done or what
> it entails.

Agreed. I've just diff'd gen_server.erl between R12B05 and R13B01 and
can't see anything relating to this.

Matthew

[Matthew Sackman]

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.

[Ulf Wiger]

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

________________________________________________________________