I am implementing an OpenGLRenderer which reads and modifies some variables shared with the Message Thread. The API documentation of OpenGLRenderer::renderOpenGL() is unclear to me when it says that the Message Manager is locked only “If the context is attached to a component in order to do component rendering”.
My renderer attaches its context to a component in the constructor and never removes it. Also the render is not in a loop and it’s triggered only upon user actions with triggerRepaint(). However it looks like I can make no safe assumption that the message manager will be locked in renderOpenGL().
I put a call to lock the message manager at the beginning of renderOpenGL() as follows:
const MessageManagerLock mmLock(ThreadPoolJob::getCurrentThreadPoolJob()); if (!mmLock.lockWasGained()) return;
to be on the safe side and lock the MessageManager every time if not already locked. However it looks like this can lead to a deadlock with the Message Manager trying to lock the native context (already locked by the GL thread with a NativeContext::Locker in juce::OpenGLContext::renderFrame()).
So is there an easy workaround to avoid using a mutex for all the variables that are shared with the message thread ? How can I be sure that the Message Manager is always locked when my renderer’s renderOpenGL() is called ?