Thread Locals Crashing DLL on XP

After upgrading to the latest 2.0.32 tip, I experienced a strange crash on XP in a DLL built with Juce. Since it only crashed on XP, but worked fine on Windows 7 and above, it instantly smelled like something “threadish” or “IPCish” to me. The outcome of a lot of narrowing down and wild guessing was it had something to do with thread locals. Although I’m not familiar with the concept, looking at juce_TheadLocalValue.h was enlightening: Jules helpful comment pointed out that something is not working on XP and Win32 exclusively, and, without understanding what that actually is, I knew it needed to be eliminated :smiley:

Now, the switch JUCE_NO_COMPILER_THREAD_LOCAL needed to be 1 to fix my crash. The cool conditional expression that is supposed to trigger in this case did not apply here.

The reason I post this is that I feel there should be a more obvious and reliable way to tell whether a DLL project is supposed to be compatible with XP or not, so this switch can be set appropriately. Usually, if we compile for Windows, we expect the product to run on XP and above, so probably all WIN32 DLL projects may need this turned on by default?

For now I hacked the source to get my code going. How would the conditional expression be rewritten to cover this case? Is there an alternative way to deal with this?

Anyone know if there’s some kind of predefined symbol that’s set whenever it’s compiling a DLL? If so, I could add that to the test expression, but if not, setting JUCE_NO_COMPILER_THREAD_LOCAL to 1 for your project is a perfectly clean way to get the same result.

There is one: _DLL is defined when /MD or /MDd (Multithread DLL) is specified. This may however not be the case with plug-ins. I could not find /MD or /MDd in Introjucer generated plug-in projects.
http://msdn.microsoft.com/en-us/library/b0084kay(v=vs.71).aspx

There’s also _WINDLL but that seems to be used only for MFC DLL projects generated by a wizard. Introjucer seems to use it for plug-ins.
http://msdn.microsoft.com/en-us/library/aa235516(v=vs.60).aspx

Build settings for a regular WIN32 DLL do not include a predefined macro at compile time.
http://msdn.microsoft.com/en-us/library/aa235524(v=vs.60).aspx

It might be safe to test for_WINDLL or _DLL. If I understand correctly, thread local variables are supported by standalone executables on XP, just not DLLs? Is it harmful to do without them?

_DLL actually has a different meaning, it’s about which C library to link.

Yeah, it’s not harmful. Just go with JUCE_NO_COMPILER_THREAD_LOCAL = 1