Re: [boost] Re: Windows MSVC thread exit handler for staticly linkedBoost.Thread

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-08-01 04:01:34

Tony Juricic wrote:
> Since we are sort of messing with PEF and considering a separate DLL for
> catching thread exit notifications (it won't work with threads forcefully
> terminated with TerminateThread Win32 API) perhaps hooking Win32 API calls
> ExitThread and TerminateThread would be one solution?

I do not think so.

1. we are not "messing"with PE - TSL callback procedure is 
well-documented in PE file format, see section 6.7.2 of document 
"Microsoft Portable Executable and Common Object File Format 
Specification" (available 
http://www.openwatcom.org/ftp/devel/docs/pecoff.pdf and in other 
places). It's also well handled by Windows NT line of OSes (and possibly 
older versions of Windows too)

2. we are acually "messing" with the compiler (and linker), trying to 
force it to put right data in the executable file. So far we succeed 
only with MSVC71. "messing" with compilers is something that members of 
Boost community are already pretty familiar with. We may also seek other 
*supported* ways to attach our function to module loader list.

3. ThreadTerminate is something that I believe we do not need to handle. 
This function does really not free anything, not even TLS nor stack. 
Thus freeing anything in higher-level code (like Boost) would be just 
silly. It's supposed to be called only in handling of SEH exceptions, 
logic errors or when terminating thread from outside, eg. when  thread 
is in "undefined" ("while(1);") state. Trying to free its resource is 
similar to "recovering" from undefined behaviour (you simply can't do it 
well). If we really want to handle thread termination, 
RegisterWaitForSingleObject should suffice.

4. ExitThread and TerminateThread are both defined in kernel32.dll . 
These functions do use some lower-level functionality from ntdll.dll. 
However ExitThread is the only Windows function that fully implements 
exiting from thread (ie. notyfing loaded modules, freeing TLS, freeing 
FLS, freeing stack and notyfing scheduler). There are no other functions 
in ntdll.dll that could be used "instead" to cleanly exit from thread in 
Win32 subsystem.

5. Microsoft already published method for hooking into system functions, 
it's called "Detours" and documented here :
http://research.microsoft.com/sn/detours/ . However I strongly believe 
we should not use it; it's useful only for very limited set of purposes 
(tracing, debuging, logging, system diagnostic) and for our users it 
would be no-no in production environment.

B.