"William E. Kempf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Edward Diener said:
> > "Alexander Terekhov" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> >>
> >> 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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to