Re: [boost] [thread] A few submissions

Subject: Re: [boost] [thread] A few submissions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-07-04 18:03:44

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?

>
> 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

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.

it isn't simply a #define because they have different semantics  
regarding construction/destruction, and types that are support. the  
final interface could support other POD types besides pointers though.