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.

[essen]

I don't think it's too far fetched to expect system messages to be handled optionally as priority messages. Imagine you are debugging an overloaded process and you are trying to get the process state. Today you must be very patient. With priority system messages you can immediately debug things. If I understand correctly aliases would enable that scenario (since system messages are ultimately normal messages that could be prioritised).

[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

[josevalim]

I dropped a longer comment on the Erlang Forum but I worry that relying on runtime behaviour, such as aliasing and distribution of said aliases, to control the priority messages may complicate correctness analysis in the future, or even general understanding of the code. I'd generally strive to make it clearer both in the sender and the receiver that a given message is a priority.

[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.

[michalmuskala]

As I suggested in erlang/otp#8371 (comment), a separate mailbox could lead a way to a very trivial implementation of a worker pool - multiple workers receiving from a shared mailbox. In general, MPMC queues would be quite useful, as they are widely used in the industry (assuming current mailboxes are MPSC queues).
Arguably, it also makes the ordering semantics much simpler - the order is maintained within a mailbox, and switching mailboxes for a process would be explicit.

[juhlig]

Interesting idea... but also a massive change, not only in terms of behind-the-scenes changes but also in how a user would have to think about messages (or signals) in general. Generally, taking into account "making message queues a first-class object" as said in erlang/otp#8371 (comment), it would amount to "process B can "steal" messages from the inbox of process A", something that you definitely have to get used to after years (decades?) of being an Erlang user.

If you want to have MPMC queues, baked into the language or not, I think they have to be something distinctly different from process message (signal) queues. Ie, you can't replace one with the other, at least not without massive repercussions.

I guess what I'm trying so say is that the fact that it does make a particular use case trivial as you put it, doesn't mean that it is a generally good idea, in the wider sense. Put differently, it is IMO a different idea suited for a different use case, and therefore outside of the scope of this EEP.

[essen]

If you're going to have a shared mailbox that you need to switch to, then it can just be a new module that takes care of all implementation details. Today we have processes and tables; tomorrow we could have a third type of object that is a mailbox, or a queue, that multiple processes could use. It could have semantics similar to Erlang process mailboxes, only shared (you wouldn't replace RabbitMQ with it, but it could help in various node-local scenarios). I don't think it requires special syntax, only considerations around how best to get messages from these queues.

[rickard-green]

I've updated the EEP. The process_flag/2 flags for identifying messages to handle as priority messages have been replaced by priority aliases and priority options.