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.