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

[Ulf Wiger]

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