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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-02-26 10:47:36

Edward Diener said:
> 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.

What forms of "thread specific data" are there besides TLS?  How does
DllMain play into how you clean up such data?

>>  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.

I have to disagree.  First, I don't think you *can* solve the reentrancy
problems with DllMain.  Second, even if you could, DllMain is the wrong
solution for cleanup.  Something as simple as a thread exit routine would
be a much better "partial" solution, though it's silly not to add this
directly to TlsAlloc() (or a TlsAllocEx() to keep backwards
compatibility).

> 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.

I can give you some names.  I could also give some e-mail addresses,
though that might be considered bad netiquette.  But MS *does* have
someone who's supposed to champion for us developers... Herb Sutter.  If
you want to campaign for this, send him a polite e-mail and I'm sure he'll
discuss this with the appropriate folks at MS.  I've already done so (as
well as voiced the same opinions to some actual MS developers), but my
lone voice may not be enough for them to prioritize this in any way.

-- 
William E. Kempf