Added some comments regarding MessageManagerLocks

modules/juce_events/messages/juce_MessageManager.h

@@ -243,6 +243,9 @@ private:
     Obviously be careful not to create one of these and leave it lying around, or
     your app will grind to a halt!
 
+    MessageManagerLocks are re-entrant, so can be safely nested if the current thread
+    already has the lock.
+
     Another caveat is that using this in conjunction with other CriticalSections
     can create lots of interesting ways of producing a deadlock! In particular, if
     your message thread calls stopThread() for a thread that uses these locks,

modules/juce_opengl/opengl/juce_OpenGLRenderer.h

@@ -50,6 +50,8 @@ public:
     /** Called when you should render the next openGL frame.
         Note that this callback will be made on a background thread, not the message
         thread, so make sure that your implementation is thread-safe.
+        If the context is attached to a component in order to do component rendering,
+        then the MessageManager may be locked when this callback is made.
         For information about how to trigger a render callback, see
         OpenGLContext::triggerRepaint() and OpenGLContext::setContinuousRepainting().
     */