Priority Messages

[rickard-green]

In some scenarios it is important to propagate certain information to a process quickly without the receiving process having to search the whole message queue which can become very inefficient if the message queue is long. This EEP introduces the concept of priority messages to the language which aim to solve this issue.

[Maria-12648430]

Pretty cool, I was hoping for something like this for a while ❤️

[Maria-12648430]

Or the situation could have resolved itself by then (like, if the messages occur in sudden bursts in a by and large relaxed scenario), at which point it would be too late to change handling strategies.

[rickard-green]

Yes, the message comes so late that it does not reflect the current state and you may not want to act on it. I'll rewrite this.

[Maria-12648430]

If a sending process specified in a priority process flag exits, will it automatically be removed from the process flags of the receiver?

[rickard-green]

In the reference implementation this is currently not done, but this can be implemented.

[Maria-12648430]

I wonder, how could this be put to work for system messages originating from sys and, by extension, from proc_lib? One would probably want to prioritize those, but AFAICT the sending process is the calling or a freshly spawned process, ie it can't be known to set the SenderPid for the priority_marked_message flag in the receiving process.

[Maria-12648430]

Now that I think about it, this restriction to prioritize messages from a specific sender pid comes with a catch.

Contrived example:
Let's say a process A configures priority_marked_message for messages from another process B. Process B however starts another process C to perform some complicated task (in order to stay itself responsive meanwhile), and in the end this process C should send a priority message on behalf of process B to process A. But since process C is not configured for priority_marked_message in process A, this message (which, again, is sent on behalf of but not by process B) won't be prioritized in the mailbox of process A.

So, as a first idea, maybe priority_marked_message should accept aliases too?

[rickard-green]

I wonder, how could this be put to work for system messages originating from sys and, by extension, from proc_lib?

To me it feels a bit like stretching what the priority messages was intended for

[rickard-green]

So, as a first idea, maybe priority_marked_message should accept aliases too?

Hmm, I like it. Perhaps the priority option can be replaced with priority aliases all together.

[Maria-12648430]

IMO, keeping reception order is important, imperative, the only sensible thing to do. More so since the receiving process can't distinguish prioritized from ordinary messages.

[mikpe]

"received" here doesn't mean "returned by receive" I take it, since the whole point of this proposal is to change that order?

[Maria-12648430]

Certainly, but it leads to an interesting point.

If the order of events turns out like this...

1. process A sends ordinary message M to process B
2. process A sends prio message P to process B
3. process B calls receive
4. process B calls receive

... then process B will receive the messages in order P then M.

However, if the order of events turns out like this...

1. process A sends ordinary message M to process B
2. process B calls receive
3. process A sends prio message P to process B
4. process B calls receive

... then process B will receive the messages in order M then P.

To be clear, that is pretty much as expected. It could/should be mentioned maybe.

[rickard-green]

"received" here doesn't mean "returned by receive" I take it, since the whole point of this proposal is to change that order?

Correct. The signal is received before it is inserted into the message queue. The name of the receive expression is in my opinion quite misleading. A less misleading name (although not as nice name) could have been fetch_message_from_message_queue.

[mikpe]

I think this point should be emphasized. Disabling the message receive order guarantees should be opt-in and based on explicit agreement between sender and receiver (which may be the same module).

[Maria-12648430]

I guess when you say "the same module" you really mean "the same process"? 😅

[mikpe]

No, I mean the same module. Say a gen_server where an API function (called from outside the server process) ends up passing a priority message to the server process -- the code for both sender and receiver is in the same module.

[Maria-12648430]

Hm, ok, after re-reading the rest of the paragraph I get that. However, the significance of the module from which a call is made is unclear to me. Why does it matter? 🤔

[mikpe]

The only significance is that with both sender and receiver in the same module they are in a better position to agree on the validity of using priority messages, which otherwise would be totally invalid.

My point is that priority messages break long-standing Erlang semantics and are totally invalid in the general case. They must be opt-in, which requires a close relationship between sender and receiver.

[mikpe]

I'd say MUST not needs.

[rickard-green]

I've rephrased this.

[Maria-12648430]

Should there be an !-like operator for sending messages prioritized (like, say, !!)? Probably not, having a convenient operator may lead to abuse and/or over-use. Also, it would be somewhat hard to factor hypothetical priority levels into it.

[essen]

I don't think we want to encourage the use of priority messages that much. They should be rare enough to not need an operator.

[potatosalad]

Would it be possible to allow something like this for allowing any process on the current node to send priority messages to the receiving process?

process_flag({priority_marked_message, local}, true).

Otherwise, for cases like overload protection where it may be a system-wide decision to change strategies, it could require having a secondary process used solely for the purpose of forwarding high priority messages to the receiving process based them opting in to receive priority messages from this secondary proxy process.

Demonstration the "priority proxy" thing:

-module(eep76_local_senders).

worker_start() ->
    spawn(fun() -> worker_init(foo) end).

worker_init(Strategy) ->
    % Option 1: spawn a "proxy" process
    PriorityProxy = priority_proxy_start(self()),
    erlang:process_flag({priority_marked_message, PriorityProxy}, true),

    % Option 2: allow priority message from any local process
    erlang:process_flag({priority_marked_message, local}, true),

    true = erlang:register(worker, self()),
    worker_loop(Strategy).

worker_loop(Strategy) ->
    receive
        {change_strategy, NewStrategy} ->
            worker_loop(NewStrategy)
    end.

priority_proxy_start(Worker) ->
    spawn(fun() -> priority_proxy_init(Worker) end).

priority_proxy_init(Worker) ->
    true = erlang:register(priority_proxy, self()),
    priority_proxy_loop(Worker).

priority_proxy_loop(Worker) ->
    receive
        Message ->
            erlang:send(Worker, Message, [priority])
            priority_proxy_loop(Worker)
    end.

change_strategy(Strategy) ->
    spawn(fun() ->
        % Option 1: send to a "proxy" process
        erlang:send(priority_proxy, {change_strategy, Strategy}, [priority])
        
        % Option 2: send directly to the worker process
        erlang:send(worker, {change_strategy, Strategy}, [priority])
    end).

[rickard-green]

I think that @Maria-12648430's suggestion could solve this by distributing a priority alias to the processes that should be able to send such priority messages.

[potatosalad]

Double checking my understanding, that idea might look like this, right?

% receiver
PriorityAlias = erlang:alias([priority]).
% distribute to "senders" out of band

% sender (any process)
PriorityAlias ! priority_message_here.

[rickard-green]

@potatosalad Yes

[essen]

If you send priority messages fast enough, the process may never get to read normal messages again. This warrants a big warning in the documentation, or to make the implementation read from both queues. Considering the intended use case, the former sounds good enough.

[rickard-green]

If you send priority messages fast enough, the process may never get to read normal messages again. This warrants a big warning in the documentation, or to make the implementation read from both queues. Considering the intended use case, the former sounds good enough.

Yes, but I'd argue that you are misusing the feature if that should happen and quite a lot of features can destroy a system if misused (for example process priorities). Agree about the warning.