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.