Consider a Thread that has opened several interfaces for writing. Now a remote peer opens some of those interfaces for reading. If the thread writes the interfaces one after another in quick succession, many messages need to be enqueued for the remote client. But already the first message causes a wakeup of the network sender. It wakes up, locks the queue and starts sending messages. If the thread tries to write more interfaces it has to wait for the very same queue lock, because the blackboard network handler registered as a notifier for the interface and tries to enqueue a change notification message during the notification, causing a performance penalty.

We have seen a case with the leg tracker and LaserGUI that causes a bad performance penalty, unfortunately especially for fast running plugins.

This problem needs to be fixed, for instance by using a double buffer queue for the network sender message queue, where only the switching between two queues needs to be locked. Care needs to be taken to not miss any wakeups.

Thanks to Masrur for spotting this problem. A fix is being implemented.