JUCE potentially locking on the audio thread

A Message on the message thread is a refcounted pointer. Usually, the message queue is the only one holding a reference to the message - so after it was delievered, it goes out of scope and is deleted.

AsyncUpdater however keeps a refcounted pointer to the message that it posts to the message queue. That means, after the message was delivered, it remains alive and is re-used the next time by AsyncUpdater.
So that means, no memory allocation is required. AsyncUpdater keeps posting the exact same message object to the queue again and again.
If your message queue is very full, the RefCountedArray inside the MessageQueue class must be increased in size - this includes a memory allocation but it only happens when the queue is full - in this case, you probably have a slowed-down system anyway so it doesn’t really matter.

As for the locking - there is a CriticalSection involved when the MessageQueue adds the message in MessageQueue::post(). The array of messages is a RefCountedArray with a CriticalSection. Theoretically, the MessageThread could be removing a message from the queue and be interrupted right in that moment.

I guess, it would be a nice improvement to switch to a lock free fifo (AbstractFifo class) for the message queue. We could request that, however it would limit the number of messages allowed to a fixed number.