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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk