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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk