|
Boost : |
From: Edward Diener (eddielee_at_[hidden])
Date: 2003-02-24 19:29:58
"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:1478.167.16.75.11.1046125028.squirrel_at_frodo.kempf-ville.com...
>
> Edward Diener said:
> > "Alexander Terekhov" <terekhov_at_[hidden]> wrote in message
> > news:3E5A1583.775485FC_at_web.de...
> >>
> >> Ken Hagan wrote:
> >> >
> >> > Alexander Terekhov wrote:
> >> > >
> >> > > I, for one, believe strongly that "&k" is nothing but
> >> > >
> >> > > "static_cast<typeof(k)*>(pthread_getspecific(__k_key));"
> >> > >
> >> > > It *isn't* a compile-time constant (just like &errno isn't a
> >> compile time constant).
> >> >
> >> > MSVC has no pthread_getspecific(), so I venture to suggest that your
> >> belief probably isn't valid for that compiler.
> >>
> >> Uhmm. In return, I venture to suggest that MS-TLS can and shall be
> >> characterized as ``utterly busted.''
> >>
> >> "If a DLL declares any nonlocal data or object as __declspec(thread),
> >> it can cause a protection fault if dynamically loaded."
> >
> > This is well-known by many and has never been hidden by MS. It doesn't
> > mean __declspec(thread) is busted, it just means that it is limited to
> > only those cases in which the DLL is not dynamically loaded, which is
> > the vast majority of cases. Of course to make TLS completely foolproof,
> > one does not use __declspec(thread) but instead one uses the Win32 TLS
> > API functions instead.
>
> Where you run into issues with TLS cleanup ;).
Such as ?
You can clean up your own TLS index ( or indices ) in your DllMain routine
when the seond parameter is DLL_PROCESS_DETACH, meaning that your process is
being exited. AFAIK this is the standard way to do this.
>
> I won't be as critical as Alexander, but I will agree that the MS TLS
> implementation has serious design issues which need to be corrected.
OK, this isn't the place to debate Windows TLS, but I have not run into such
design issues myself.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk