[erlang-patches] Selectively receive system messages in gen_server and gen_fsm

[Patrik Nyblom]

You're absolutely right, the optimization can kick in on the client 
side, not on the server side. The server handles messages in order of 
arrival.

The change is mute, the messages will still be handled in order, so the 
patch should be withdrawn.

To clarify: Selective receive kicks in (as Ulf explained) only if there 
no catch-all. Each message is conceptually matched against *the whole* 
receive clause before moving on to the next message in the queue. A 
catch-all always matches the first message, so there will be no 
"selective receive" or rather, the "selective receive" will select the 
first matching message, which is always the first message. As Ulf also 
pointed out, system messaages should also be handled in-order, that 
should not be changed, as for example code change is a system message 
that shall not be reordered.

Cheers,
/Patrik

On 01/02/2013 11:13 AM, Ulf Wiger wrote:
> The optimizations cannot kick in here*, and I don't see that using selective receive in this case even makes a difference. Given that each receive clause has a catch-all clause, the first message in the queue will always match, which is arguably the way it should be (and must be, for backward compatibility reasons if nothing else). Thus, there is no need for the optimization, which serves to avoid scanning all messages in a possibly very long message queue.
>
> BR,
> Ulf W
>
> * The trick of the optimization is that if a unique reference is created *in the same scope* and just before the receive statement, the compiler can mark the end of the message queue and jump right to it - but only if the receive clauses all pattern-match on the newly created unique reference. Here, there is no such reference, and the receive statement contains a catch-all.
>
> On 26 Dec 2012, at 16:35, Pedram Nimreezi wrote:
>
>> The gen_server and gen_fsm modules do not selectively receive system messages.
>>
>> This commit addresses that and allows for them to be consistent with gen_event,
>> as well as possibly taking advantage of the recent improvements to
>> selective receive.
>>
>>         https://github.com/DeadZen/otp/compare/maint...system-selective-receive
>>         https://github.com/DeadZen/otp/compare/maint...system-selective-receive.patch
>>
>> git fetch git://github.com/DeadZen/otp.git system-selective-receive
>>
>> Supplemental Questions...
>>   1. I believe, but I am not sure if the selective receive call
>> optimization triggers... seems like it should.
>>   2. I see that gen_event does do a selective receive, and I believe
>> this is more correct.. is that true?
>>          https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_event.erl#L231
>>     <- does
>>          https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_fsm.erl#L424
>>       <- does not
>>          https://github.com/DeadZen/otp/blob/maint/lib/stdlib/src/gen_server.erl#L374
>>    <- does not
>>   3. Is gen_event a more recent erlang behaviour than gen_server and gen_fsm?
>>
>>
>>
>> -- 
>> /* Sincerely
>> --------------------------------------------------------------
>> Pedram Nimreezi - Chief Technology Officer  */
>>
>> // The hardest part of design … is keeping features out. - Donald Norman
>> _______________________________________________
>> erlang-patches mailing list
>> erlang-patches@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-patches
> Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
> http://feuerlabs.com
>
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches