Race in thread shutdown in imm32?

[James McKenzie]

Rob Shearman wrote:
> 2008/11/14 Dan Kegel <dank at kegel.com>:
>   
>> I'm seeing the following valgrind warning
>> in three out of eight runs under heavy load:
>>
>> InvalidRead
>>  IMM_FreeThreadData:233
>>  DllMain:382
>>  __wine_spec_dll_entry:40
>>  MODULE_InitDLL:911
>>  LdrShutdownThread:2174
>>  call_thread_func:403
>>  start_thread:444
>>
>> It kind of feels like a race between thread shutdown and process shutdown.
>> Does that ring a bell with anyone?
>>     
>
> IMM_FreeThreadData can crash if TlsGetValue returns a NULL pointer. On
> first glance, it doesn't appear possible as IMM_InitThreadData is
> called for every thread and on process startup. However, as you
> surmise, it is possible in Wine for a thread to exit after the main
> process has shut down (i.e. TlsFree(tlsIndex) has been called) and the
> TLS area has been cleared, causing TlsGetValue to return 0.
>
> I believe that Windows terminates all threads on process exit, which
> would solve this problem. However, the issue could trivially worked
> around by introducing a NULL pointer check in IMM_FreeThreadData. It
> would also be a good idea to set tlsIndex to TLS_OUT_OF_INDEXES after
> TlsFree is called to avoid the possibility of using an un-allocated
> TLS index.
>
>   
The question is how does Windows implement this feature?  Does it throw
a 'kill' for all threads and then follows with a 'kill' for the entire
process which may hang if one of the threads will not die?  If this is
the method, we should duplicate it, but do a better job of handing the
'threads that will not die', IMHO.

I'll look at the MSDN page that Ge van Geldorp pointed out to see if
this is discussed.