On 05.07.2010 2:03, Stefan Strasser wrote:
Zitat von Andrey Semashev <andrey.semashev@gmail.com>:
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'm not too familiar with delay-loading, but why can't these platforms be supported by hiding the TLS-access behind a function call so it always originates from the same module?
I'm not sure I understand how it helps. Could you elaborate? The main problem is that you can't guarantee that _any_ boost module is linked with the main executable. Therefore, you can't define a module that would define these compiler-TLS variables.
in that case, I guess I am suggesting to add a public interface like static_thread_specific_ptr, to support the semantics of __declspec(thread)/__thread/thread_local, i.e. crash when used from delay-loaded modules on platforms that don't support it.
That is a different extension from what I am proposing. But frankly speaking, I don't see much use from it if it crashes on some setups and I can't detect such setups in my code that uses this component.