[boost] boost::thread TLS atexitthread DLL et.al.

From: Roland (roland.schwarz_at_[hidden])
Date: 2004-07-23 06:19:12

After having been off the list for a while now, because of
other things to do, I'd like to share some thought about
the still not solved question of TLS on Windows.

As far as I remember the original author of the thread
library (Bill Kempf) intended the thread local storage to be usable
in an orthogonal way to boost::threads, i.e. TLS should
be cleaned up even when used in the context of native
threads.

He came up with a solution of using a DLL to catch the
very last breath of the thread. (I proposed a "piggy pack"
DLL that can be embedded in the main executable, to
get rid of the need to separately distribute a DLL file.)

Now while rethinking the thing I have serious reservations
about the DLL solution: The exit and cleanup is getting
called AFTER the C-runtime library has been de-initialized
for the thread. Is it save then to call any of the library functions
in the yet "zombied" thread? May I even call free or delete on
objects that have been created in context of the thread?

Extending this question to threads that have been created
by other means (including boost::thread) this means
the exit handler must not access any features that have
been in control of the thread mechanism.

For me this means either to drop the (desirable) requirement
of orthogonality and require the thread beeing created
and managed by boost when using TLS, or force the
user to obey strict rules about what she is allowed to do
in an exit handler (destructor in turn of an object).

To me the latter seems less appealing than the first.

Yet another idea would be to require at least the availability
of the C-library at destruction time, but require that the 
destructor must not access any thread specific (i.e. boost
thread) data.

Someone in this list has pointed out the existence of a
TLS destructor list in the PE header of executables. I have
digged into this a little. While current compilers do not
yet make use of this field it still would not answer all
questions. (Perhaps that is the reason why they are not
currently supporting it?)

However this destructor list would need to be called by
whichever library has created global objects. (Normally
this is the C/C++ runtime stub.)

It definitely cannot be the resonsibility of the operating
system to call this list (at least in my opinion).

Wrapping it up:
Having the C/C++ runtime available at thread exit seems
desirable to me.

Calling the exithandler from the DLL (THREAD_DETACH)
is too late.

Calling the exit handler from within _endthread seems
desirable (and can be reasonably expected to be
supported by compilers one time.)

Fortunately there is a chance to trick the _endthread to call
arbitrary exit functions by making use of the fp-init/deinit
hook.

I will try to provide example code, but also post this
at the same time to get your thoughts about this.

Roland