ThreadPoolJob in destructor of a statically allocated object

#1

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:

static VoidArray runningThreads (4);
static CriticalSection runningThreadsLock;

are getting destroyed before my destructor runs.

Can you suggest a way to ensure that these objects stay around long enough for my destructor to run?

Thanks for your help.

-DB

#2

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.

#3

Yes, madness.

The reason for my madness at the moment is QuickTime. It comes from here:

http://developer.apple.com/technotes/tn/tn2125.html#TNTAG49

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.

#4

Can’t you just use the message thread as the one that does everything?

#5

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?

-DB

#6

Well no, a command-line app won’t have a message thread, but if in a command-line app, why not just use the main thread for everything?

#7

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.

#8

You could use MessageManager::callFunctionOnMessageThread to invoke them if it’s a GUI app, I guess? I don’t know, all sounds a bit odd.

#9