On Wed, 13 Aug 2014 10:54:32 +0200, Kai Tietz
wrote:
> I am aware that emultls is pretty slow in comparison to OS-variant of
> TLS. I have prepared already implementation for it a bit,
> nevertheless I don't find enough time to push work on it. AFAIR is
> new D FE providing "native" TLS suppo
2014-08-13 11:18 GMT+02:00 lh_mouse :
> Windows native TLS has an obvious drawback that it doesn't support
> destructors natively in exe files. It should be noted that there are a number
> of workarounds for that, but all of which are workarounds.
True, but that is true for emultls, too. So I do
Windows native TLS has an obvious drawback that it doesn't support destructors
natively in exe files. It should be noted that there are a number of
workarounds for that, but all of which are workarounds. Another minor drawback
is that the total number of TLS indices per _process_ is 1088, but in
2014-08-13 10:34 GMT+02:00 Slava :
> Hi people,
>
> I'm porting a project, which uses TLS in performance-critical code. I
> currently use mingw-w64 (i686-4.9.1-posix-dwarf-rt_v3-rev0) on Win 7 SP1
> Professional x86 and libgcc_s_dw2-1!__emutls_get_address is one of the
> hotspots in the product. T
Hi people,
I'm porting a project, which uses TLS in performance-critical code. I
currently use mingw-w64 (i686-4.9.1-posix-dwarf-rt_v3-rev0) on Win 7 SP1
Professional x86 and libgcc_s_dw2-1!__emutls_get_address is one of the
hotspots in the product. Thus the question: why mingw-w64 generate
