I noticed this recent commit which, while it doesn’t change anything for the moment, made me worry about whether changes like this might occur to the API in the future.
I use isNonRealtime() on the audio thread to check whether we should lock to wait for the message thread to catch up with the audio thread in offline bounce situations. I checked the sources and saw that isNonRealtime() just returns a bool member variable, and doesn’t pose me any risk. In the future though, would a change be likely or possible which would make isNonRealtime() lock? If so, it’s not a huge deal – I can obviously just use an atomic and check for changes to realtime status in prepareToPlay (assuming prepareToPlay would be called during transitions between realtime and non-realtime states). But it’d be pretty hard to debug if I built against JUCE in 3 years and got a crackly buffer at the first playback after an offline bounce.
In general, should I look into JUCE classes to check for these sorts of things and assume they won’t change, or will these sorts of changes be possible?