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

[Pedram Nimreezi]

Good points, and I of course do not disagree, however, the purpose of
this patch was to begin this discussion.
I'd like to get some info and possibly see how a couple of things
could be addressed..
And Thank you for bringing up the code change point.
I agree that particular case should happen in the order in which it is received.

However, a few questions, that I'm pondering are:

- Why is gen_event already in the format that I've patched gen_fsm and
gen_server to be in. (this seems inconsistent, is there a reason?)

- Would it make sense to allow at least get_status system messages to
have priority, ie: so inspection is not impeded by queue size.

- Could it make sense for a process to have two queues, to separate
system messages into its own queue..

- When you say catch all, does that mean the first pattern matches are
irrelevant for selective receive if the last match is a catch all,
does this implicitly invalidate the selective receive optimization?

- Is it the intention of sys:get_status to only work when an OTP
process is unencumbered with a pretty small message queue and why?

- When I look at yes_5.erl and do a beam_disasm:file on that code, as
well as on gen.erl, (as well as copying yes_5 into some test
gen_server) doing a call(?MODULE, system, get_status) I see
recv_mark's/recv_sets showing that at least the monitor/gen:call
semantics have the selective receive optimization, could this be
extended to get_status?

-----

I do believe it is important to maintain the ability to inspect the
state of an OTP process, be consistent while maintaining backwards
compatibility..

I'm willing to work on this more and understand it may not be an easy
or even completely valid issue, but somethings didn't add up, and I
figured I'd put the issue on the table.

Thank you for the consideration

On Mon, Jan 7, 2013 at 5:48 AM, Patrik Nyblom <pan@REDACTED> wrote:
> 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
>
>
> _______________________________________________
> erlang-patches mailing list
> erlang-patches@REDACTED
> http://erlang.org/mailman/listinfo/erlang-patches



-- 
/* Sincerely
--------------------------------------------------------------
Pedram Nimreezi - Chief Technology Officer  */

// The hardest part of design … is keeping features out. - Donald Norman