When a message arrives at an inbox, the courier notifies all the actors in its listeners hash which are keyed on that inbox and clears them from the hash. A process typically adds itself to that set using wake-on-network, where it potentially supplies a lengthy list of inboxes for which it would like to wake up. This means that in the following scenario:
(wake-on-network inbox-A inbox-B)
;; P appended to listener lists for P, inbox-A, and inbox-B
;; message arrives at inbox-A, listener list for inbox-A is cleared, P wakes up
(wake-on-network inbox-A inbox-B)
;; P appended to listener lists for P, inbox-A, and inbox-B
the listener list for inbox-B now includes P twice. This pattern is fairly common, e.g., it happens within with-replies. In fact, if a message arrives at P's public inbox, then inbox-A and inbox-B will both reference P twice after the second call to wake-on-network, so this over-recording can happen without any termination in sight.
This isn't a huge leak of resources (yet), but it is unsightly and would be solved by sorting the set of listeners as something like a set (/ hash) rather than as a list.
When a message arrives at an inbox, the courier notifies all the actors in its
listenershash which are keyed on that inbox and clears them from the hash. A process typically adds itself to that set usingwake-on-network, where it potentially supplies a lengthy list of inboxes for which it would like to wake up. This means that in the following scenario:the listener list for inbox-B now includes P twice. This pattern is fairly common, e.g., it happens within
with-replies. In fact, if a message arrives at P's public inbox, then inbox-A and inbox-B will both reference P twice after the second call towake-on-network, so this over-recording can happen without any termination in sight.This isn't a huge leak of resources (yet), but it is unsightly and would be solved by sorting the set of listeners as something like a set (/ hash) rather than as a list.