The way my current is structured at the moment, I need to add a ThreadPoolJob to a ThreadPool in the destructor of a statically allocated object and I’m running into trouble.
I’m running on Windows but I think this is a platform-independent issue.
I get an access violation in CriticalSection::enter with a stack track like this:
tu_gn-test.exe!juce::CriticalSection::enter() Line 79 + 0xc bytes
tu_gn-test.exe!juce::Thread::threadEntryPoint(juce::Thread * const hread=0x00af6e80) Line 56
tu_gn-test.exe!juce::juce_threadEntryPoint(void * userData=0x00af6e80) Line 88 + 0x9 bytes
tu_gn-test.exe!juce::threadEntryProc(void * userData=0x00af6e80) Line 126 + 0x9 bytes
I think what’s happening is the statically allocated objects in juce_Thread.cpp:
erm… that sounds like madness to me - you expect to run a thread after the entire runtime has already shut down? Just make your object a DeletedAtShutdown rather than a static object.
I translate this to mean that I always need to call QuickTime from the same thread. Doing otherwise has caused me grief. So I have a ThreadPool with one thread and everything I do in QuickTime gets done in this thread. In this case I’d like to call TerminateQTML to shut down quick time,. Doing it in whatever thread happens to be running during the static destructor doesn’t work properly.
Could be, but I need to learn more about the message thread before I can say. I haven’t used it before. This code gets used in non-GUI apps. Is there a message thread in those apps?
Sometimes this code gets used in command line apps, sometimes in GUI apps…sometimes in statically allocated objects, sometimes in dynamically allocated ones…
And even in the command line apps, the code gets called from a variety of different threads, but the QuickTIme calls still need to happen from only one. I’m not always in control of when these other threads get created. A third-party DLL creates them and then calls a callback I pass in.