Apr 20, 2026

A nice benefit of this approach was that that notification map does not have to be copied and doesn't require any guards to be safely iterated, despite callers attempting to update it. Copy-free, lock-free, and the socket remains active. The one case where the caller will get blocked is when we are processing a notification and the caller is attempting to make a subscription or desubscription. In this case the channel strand posts to the notification strand and while the notifications are being process, the update job just sits in the queue. Once the notifications clear and the update job executes, its completion handler reestablishes the socket listener. But this is exactly what we want to happen. We are busy responding to the caller with notifications from a new event, and the caller is waiting to complete his new subscription/desubscription only during that time. And of course the channels are entirely independent of each other, so everything keeps moving. The server remains fully protected against DoS, as the callers do not control the rate or volume of notifications.