On 05.07.2010 0:58, Stefan Strasser wrote:
How do you work around the problem with delay loaded dlls?
I don't. I suppose platforms that have that problem can be supported by hiding the TLS vector behind a function call, or if the platform doesn't support global TLS but supports TLS that is local to the DLL the pointer to the TLS vector could be obtained under a mutex lock for each module. note that this implementation only uses one TLS variable. if it can't be supported you'd have to fall back to TlsAlloc etc.
AFAIK, Windows prior to Vista and Linux have this issue. It's a quite wide range of platforms, IMHO.
I think this rather obscure use case should not punish most use cases. Vicente has performed some performance tests of Boost.Transact (that uses static_thread_specific_ptr) on different platforms, some supporting TLS, some don't.
Well, I thought the same when I implemented the same technique in Boost.Log. I was considered otherwise when I got lots of complaints from users. Apparently, the "delay-loaded dll" is not so uncommon as it may seem. My point is that, unless it "just works", the use of this feature should be optional and disabled by default (which effectively means, disabled in 95% of cases). No matter how sad it is. :(