Boost logo

Boost :

From: Bronek Kozicki (brok_at_[hidden])
Date: 2004-07-31 10:28:51


Michel André wrote:
> RegisterWaitForSingleObject utilizes the builtin threadpool and is only
> availble in the following versions of the MS OSs which might pose a
> problem.
> Client: Requires Windows XP or Windows 2000 Professional.
> Server: Requires Windows Server 2003 or Windows 2000 Server.

That's one problem. The other is that function executed on thread exit
will be executed in different thread (well, you noticed that already),
thus will not have access to TLS of exiting thread. Actually it will be
executed after TLS has been already removed by OS. Having no access to
TLS means that it won't be able to release it's memory. Even if we store
copies of TLS pointers somewhere where they're also available after TLS
has been removed by OS, that's still bad - destructors might need
warranty that it will be executed in context of exiting thread (eg. in
order to use synchronization primitives locked somewhere in the thread
or to use fibers started in thread).

Aaron W. LaFramboise brought really good idea of using TLS function
defined in program image (ie. PE file). I didn't know that it's even
possible - you may have equivalent of "DllMain" inside .exe file :->
I've seen it's handling in Windows NT core, but didn't know how to make
OS aware that such function exists. As Aaron found, MSVC71 is capable of
preparing such PE image - I do not know about other compilers.

In case of Windows Server 2003 we also have FlsCallback (which I believe
has been designed specifically for this purpose, thus is very appealing).

In older Windows versions three other options are coming to my mind:
* using APC (unreliable and with unforeseen CPU overhead)
* manipulation in Process Environment Block structure (that's just ugly
hacking, unless we find some supported way).
* ditributing Boost.Threads with small DLL file, whose sole purpose is
to receive DLL_THREAD_DETACH notification and pass it to Threads library

B.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk