i have a thread that tries to build a SVG Drawable. This thread runs in the background loading a preparing things. Unfortunately, this causes a conflict with the message manager. A Juce assert tells me to use a MessageManagerLock, but this is bad because of two reasons:
i don’t want the background thread blocking the foreground UI, otherwise i might as well not use a thread for this at all.
i get deadlock whenever the UI is waits for the results of the thread, because the UI will, at this time, be already holding the MM lock.
Ok, so perusing the Juce code reveals the issue is because, in theory, the components being assembled by the thread could potentially be updating the screen etc. However, this is never the case, since the objects in question are yet to be used.
Now, for my purposes here, if i comment out the Juce assert that insists on the lock and ignore locking, everything works fine. i know this is fine here because of what i’m doing. But, of course, this is not true in general.
So, i was thinking of two possible ways around this for Juce.
- Factor out the SVG parsing stuff so that a bunch of Drawables could be constructed quickly from some sort of `ParsedSVGTree’ or somesuch.
- Introduce a new Component flag, eg
inactive' (as opposed to disabled), whereby components with this flag never frob the UI or the event system and therefore do not insist on, or need, a MessageManagerLock. The idea here would be to construct Drawables in aninactive’ state, and then “activate” them later before adding them to the UI.
or is there something obvious i’ve missed.