[boost] Re: Re: Re: Re: Re: Thread-Local Storage (TLS) and templates

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-02-25 18:36:07

William E. Kempf wrote:
> Edward Diener said:
>> William E. Kempf wrote:
>> I still don't think it is a TLS issue but rather a thread cleanup
>> issue and the restrictions imposed by MS's design of that situation.
>> So I can well understand your chagrin at the tricks you must do in
>> order to cleanup internal thread data when a thread exits under
>> Windows.
>
> That's a minor fine hair your splitting.  What's the difference
> between "a TLS issue" and a "thread cleanup issue" of TLS data?

Because it is a thread cleanup issue of any thread specific data, not just
TLS. No matter what the data that exists for a thread when the thread is
exited, it musty be cleaned up efficiently. A user could have objects
associated with only a particular thread and if the thread ends, it must be
able to cleanup while other threads continue running. The fact that MS says
no to this in DLL_THREAD_DETACH, that you are effectively blocking other
threads in the process until you exit the DllMain routine, is for me the
central weakness.

>  And
> if you look back, I said I wouldn't call it "broken", just that the
> "implementation has serious design issues".  So it looks like we're
> in agreement now.
>
> Want to join in my mini campaign to convince MS to fix this one?

As long as the suggested fix is to allow thread cleanup without the current
restructions on synchronization or DLL loading/unloading, sure. I don't
think you are going to change anything in the way that TLS currently works
nor should you. I am going to guess that MS is aware of this issue of thread
cleanup and that the main fix on their part would be to allow re-entrancy in
the current DllMain routine, which of course may be a big job on their part
given the amount of underlying intertwined code. The other solution(s)
involves some sort of callback as you suggested, or some other way to ensure
that a thread can be exited cleanly without blocking other threads from
running in the meantime, whether in an executable, a static LIB, or a DLL.

Knowing MS from their track record, a campaign to get them to change
anything entails working closely with one or more of their techies who can
actually understand the issues involved and get the changes to be seriously
considered. Just voicing displeasure in any public way won't do anything. If
there is a VC++ rep who now works closely with Boost to ensure VC++ .NET
conformance, he's the guy I would "badger" first, and then through him you
might be able to get to other MS techie employees.