=== Background ===
I have a question about MessageManager locks in juce_OpenGLContext.cpp. This whole post assumes that a component is attached to the OpenGL context and renderOpenGL() happens on a separate thread. I had previously been writing lock code with std::mutex to protect resources that are accessed from both my GL thread and my main JUCE message thread. I now suspect that this is not necessary. It seems that renderFrame() in juce_OpenGLContext.cpp acquires a MessageManager lock anyway, so renderOpenGL() is always mutually exclusive with the JUCE message thread.
Is my understanding here correct? I put some debug prints into renderFrame(), and it appears that the MM lock is always taken before renderOpenGL(). There’s an if()-else() path that allows for the MM lock to not be taken, but that code path never triggers (as far as I can tell).
Here’s the relevant file:
Look for the renderFrame() function, specifically.
=== Questions ===
Will the MM lock in renderFrame() ever not be acquired? It looks like this is possible if a renderFrame() happens and needsUpdating is false, but will this ever be the case?
If renderOpenGL() and the JUCE message loop both acquire the MM lock then why have them be on separate threads anyway? It seems to me that the main reason to do GL rendering on a separate thread is to prevent expensive main thread work from blocking GL rendering (and to prevent expensive GL rendering from blocking the main message thread). But if both threads acquire the MM lock then having them be separate threads in the first place feels moot. Is there something that I’m missing here?