Merge branch 'rickard/update-prio-msg-eep'

* rickard/update-prio-msg-eep:
  Update EEP 76

Author: rickard-green

eeps/eep-0076.md

@@ -1,5 +1,5 @@
     Author: Rickard Green <rickard(at)erlang(dot)org>
-    Status: Draft
+    Status: Final
     Type: Standards Track
     Created: 07-Jan-2025
     Post-History: https://erlangforums.com/t/eep-76-priority-messages
@@ -219,6 +219,12 @@ be handled as today with the exception that the process that called the
 `link/2` BIF with the `priority` option will receive a priority exit signal
 if the link is broken.
 
+If a link already exists when the `link/2` BIF with the `priority` option is
+called, the link remains but will be marked for priority handling. If a link
+which has been marked for priority handling already exists when the `link/2`
+BIF without the `priority` option or the `link/1` BIF is called, the link will
+remain, but the priority handling will be disabled.
+
 Note that priority exit signals will not have any other behavior than today
 unless the receiver is trapping exits. This since the priority messages only
 affects how messages are moved into the message queue after a signal has been
@@ -366,15 +372,8 @@ Reference Implementation
 The reference implementation can be found in [pull request 9269][] of the
 [Erlang/OTP repository][].
 
-Note that the reference implementation has not yet been updated to reflect the
-change in the proposal to use *priority aliases*, but instead implement the
-old proposal where process flags are used in order to opt-in for priority
-messages.
-
-Care has been taken to have as small impact as possible on processes not
-using priority messages. Processes not enabling reception of priority
-messages will not use any more memory at all due to the priority messages
-implementation.
+Care has been taken to have as small impact on performance and memory as
+possible especially for processes not using priority messages.
 
 A Few Notes on the Implementation
 ---------------------------------
@@ -387,20 +386,32 @@ adjustments that needs to be done to the message queue during certain
 operations. That is, the current code traversing the message queue needs to be
 prepared to encounter receive markers of different types.
 
-When the user enables reception of priority messages, a block containing three
+When the user enables reception of priority messages, a block containing two
 receive markers and an area for auxiliary data is allocated. The receive
-markers are of new types distinguishable from the already existing receive
-markers. The auxiliary data, among other things, contains a red/black search
-tree containing information about what type of messages the process accepts as
-priority messages. All memory allocated for handling of priority messages is
-referred to from this memory block.
-
-The first and the second receive markers are inserted at the start of the
-message queue. The first marker marks the start of priority messages and the
-second marks the end of priority messages. The first marker also serves as an
-entrance for finding all information about the priority message handling. When
-a priority message is accepted it will be inserted just before the end marker.
-The third marker is inserted in the message queue when we need to remember a
+markers in this memory block are of new types distinguishable from the already
+existing receive markers. All memory allocated for handling of priority
+messages is referred to from this memory block.
+
+This memory block for priority message reception is referred to from *process
+specific data*. Process specific data is only used by processes that enable
+functionality that seldom is used. Since the memory used for priority message
+reception is referred to from process specific data, memory usage will only
+increase for processes using process specific data. If such processes have not
+enabled priority message reception, only one machine word more of data will be
+used.
+
+While no priority messages exist in the message queue, handling of messages is
+done exactly the same way for a process that has enabled priority message
+reception as for a process that has not. When a priority message is accepted
+into the message queue, a *priority message end marker* is inserted at the
+start of the message queue and then the priority message is inserted just
+before the marker. If yet another priority message is accepted while the first
+priority message still is in the queue, it will be inserted just before the
+priority message end marker. The priority message end marker will remain in the
+message queue until no priority messages exist in the queue. At that point, the
+priority message end marker will be removed form the queue.
+
+The second marker is inserted in the message queue when we need to remember a
 place in the message queue. This is needed when a priority message is accepted
 while we currently are traversing the message queue.
 
@@ -422,6 +433,42 @@ the reference, but I see that as a premature optimization. A process is not
 expected to accumulate a large amount of priority messages. If so, the process
 has used priority messages in a way not intended.
 
+### Determining if a Message Should be Accepted as a Priority Message
+
+We more or less have two scenarios. In the first scenario, the signal was sent
+by calling the `erlang:send/3` BIF or the `erlang:exit/3` BIF using a priority
+alias and the `priority` option. In the second scenario, the signal was sent
+due to a link being broken or a monitor being triggered where the link or
+monitor was set up by calling the `link/2` BIF or the `monitor/3` BIF with the
+`priority` option.
+
+We first look at the first scenario. The receiver already has local information
+about all active aliases for itself. When an alias message is received, it
+looks up the local information about the alias. If the alias has been created
+using the `priority` option, a priority bit is set in the local information
+about the alias. A signal which has been sent using the `priority` option also
+contains a bit set indicating that the priority option was used. In order to
+determine whether or not to accept a signal as a priority message, the receiver
+only needs to check that both of these priority bits are set.
+
+When it comes to the second scenario. If an exit signal due to a broken link
+or a monitor signal due to a triggered monitor should be handled as a priority
+message, the link should have been set up by the `link/2` BIF using the
+`priority` option or the monitor should have been set up by the `monitor/3`
+BIF using the `priority` option. In both cases, a priority bit will be set in
+the local information about the link or monitor. When such a signal is
+received, the receiver only needs to check if the priority bit is set in the
+local data in order to determine if it should be accepted as a priority
+message or not.
+
+In both scenarios, the receiving process has local data associated with the
+signal that it already needs to look up unrelated to priority messages. The
+only extra work due to priority messages that it needs to do is to check if
+the priority bit is set in this local data, and for signals sent using the
+`erlang:send/3` or `erlang:exit/3` BIFs also check if the priority bit is set
+in the signal. In other words, the operation of determining whether or not a
+message should be accepted as a priority message is extremely cheap.
+
 ### Priority Messages in Transit
 
 There exists a number of different types of signals. For each type of signal an
@@ -452,12 +499,13 @@ Change Log
 
 * 2025-01-22: The `process_flag/2` flags for identifying messages to handle as
   priority messages were replaced by *priority aliases* and priority options.
+* 2025-02-22: Updated information on the reference implementation.
+* 2025-02-22: Clarified how the `link()` BIFs affects already existing links.
+* 2025-02-22: Changed the state of the EEP to *final*.
 
 [Message Reception]: eep-0076-1.png
-    "Message Reception"
 
 [Priority Message Reception]: eep-0076-2.png
-    "Priority Message Reception"
 
 [the signal ordering guarantee]: https://www.erlang.org/doc/system/ref_man_processes.html#delivery-of-signals