Apparently, JUCE uses macOS APIs that are meant to be used from the main thread only from a background thread.
Is there an official comment on that ? Like “you can not use the Main Thread Checker” with JUCE or “we are ware of the issue and work on a solution” ?
Thanks
Wolfgang
Well, the official comment is that we didn’t know there was an issue! Which calls are causing the problem?
NSViewComponentPeer getBounds for instance
Hmm… But where is that getting called from a background thread? You shouldn’t call any Component or GUI methods from a background thread regardless of the OS, and I can’t think of anywhere in our code where that’d happen…
The OpenGL renderer uses this.
Ah, of course.
That’s done deliberately and is definitely thread-safe (it locks the main thread to make sure the background thread won’t cause any races), but I guess if it’s complaining we’ll need to find a way to silence the spurious warnings. I’ll have a look into it and see if there’s anything we can do.
OK, this is a bit of a problem.
For the GL renderer, we don’t have a choice about which thread we use - the code that renders the GUI must run on the GL thread because that’s how GL does things. What we do to make things thread-safe is to suspend the message thread while it’s active, and that works just fine.
However, this does trigger the new message-thread checker, and AFAICT there’s no way for us to dynamically disable it for the bits we know are safe, the only way to stop it complaining is to turn it off in your project.
On the plus side, it does only seem to trigger a warning once per location in the code, and only happens in a couple of places, so you can just ignore it and continue, and your app should run.
Honestly don’t think there’s much else we could do here as a workaround! Ideas welcome, but I think that for people doing GL GUIs it’ll just have to be something you turn off.
It looks like there are more issues to silence, but I guess they will be fixed over time, when you run into them.
Well maybe not!
Like I said, it’s a bit of a catch-22 because we have functions that need to call both GL functions and NSView classes. The GL functions MUST be called on this background thread for them to succeed. It’s impossible for us to move everything to the message thread in this case.
Obviously if there are any other situations where we can fix these warnings, we will do, but I think GL is a bit of a special case because of ancient GL requirements that mean you have to use a context on a specific thread.
