From 82b0a3628b3fce743b398458e0a15a687e1b720f Mon Sep 17 00:00:00 2001 From: jules Date: Mon, 14 Dec 2015 09:48:25 +0000 Subject: [PATCH] Added some comments regarding MessageManagerLocks --- modules/juce_events/messages/juce_MessageManager.h | 3 +++ modules/juce_opengl/opengl/juce_OpenGLRenderer.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/modules/juce_events/messages/juce_MessageManager.h b/modules/juce_events/messages/juce_MessageManager.h index 0a27162bea..9373205850 100644 --- a/modules/juce_events/messages/juce_MessageManager.h +++ b/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, diff --git a/modules/juce_opengl/opengl/juce_OpenGLRenderer.h b/modules/juce_opengl/opengl/juce_OpenGLRenderer.h index d932093a45..4c1cb98623 100644 --- a/modules/juce_opengl/opengl/juce_OpenGLRenderer.h +++ b/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(). */