Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2010-07-04 18:13:41

On 05.07.2010 2:03, Stefan Strasser wrote:
> Zitat von Andrey Semashev <andrey.semashev_at_[hidden]>:
>
>> 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.