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