This looks so obvious I feel like I’m missing something…
Toying around with clang20’s rtsan, I noticed that AudioProcessorPlayer::audioDeviceIOCallbackWithContextacquires a (real, blocking) lock. Obviously it is intended to be called on the audio thread. Is this really justified? Same thing goes for AudioProcessor::callbackLock btw.
Sounds like a SpinLock job to me… what am I missing?
There is a lot of old code in Juce that was written when things like being lock free wasn’t considered as important as it is today. The thinking may have been that the locks will not be actually contested often and if they actually block, it will happen in a situation where the audio will somehow be disrupted anyway.
Thanks @xenakios. This one is completely contained, seems like an easy fix… maybe the team will pick up on this?
Yeah some of the Juce CriticalSection locks could probably be changed to Juce SpinLocks, but the latter have the caveat that they are not re-entrant, so all the code would have to be checked that the SpinLock::enter method is never called from a thread where it has already been called.
