Re: [AD] dll_tls for MSVC

Are you sure non-DLL TLS works on MinGW dynamic builds? Can you point to some documentation that says so or test it? I may be being paranoid but it bothers me that it’s not going to get tested.

The patch looks fine otherwise. I’ll look at the other one and apply if you can confirm the question about MinGW.

Thanks,

Trent

From: Markus Henschel [mailto:markus.henschel@xxxxxxxxxx]
Sent: January 6, 2014 10:43 AM
To: alleg-developers@xxxxxxxxxx
Subject: [AD] dll_tls for MSVC

Happy New Year!

I tried to use the dll-tls implementation of Allegro with MSVC. If I enable WANT_DLL_TLS in the CMAKE build it simply gets disabled again by this code in CMakeLists.txt:

if(MSVC)

# MSVC never needs DLL TLS and it just confuses

set(ALLEGRO_CFG_DLL_TLS 0)

…

I think I have a case where I need dll-tls because I have to support WindowsXP. In WindowsXP compiler supported TLS doesn’t work for dlls that are dynamically loaded at runtime using LoadLibrary/LoadLibraryEx. I get chrashes as soon as the thread local storage is accessed.

http://support.microsoft.com/kb/118816/en-us

Windows Vista and above don’t have this problem.

I’m using allegro with .NET so I cannot load the allegro dll implicitly by the import table of the executable. The only choice I have is using dll-tls. Are there any objections to removing the line mentioned above from CMakeLists.txt so the dll-tls implementation can be used again with MSVC? I attached a patch for that. It also disables dll-tls by default so it is only used if explicitely requested or if there is no other choice (older mingw versions).

I noticed that the dll-tls implementation creates a thread_local_state object for every thread created by the process after the allegro dll has been loaded. This is inefficient because most threads probably won’t need the object. I also observed memory leaks because some threads in my process are being created after the allegro dll has been loaded but are still running after the allegro dll is unloaded. In this case the thread_local_state object leaks. I fixed this by doing lazy initialization of thread_local_state. In this case only threads that access the thread local object actually get one. There is still potential for memory leaks if one of these threads lives longer than the allegro dll is still loaded but this is much less likely. I also attached a patch for that.

It would be nice if some of you could review/submit these patches.

Thanks

Markus Henschel