Found a undocumented way to have thread_local variables in DLLs

From	Bonita Montero <Bonita.Montero@gmail.com>
Newsgroups	comp.lang.c++, comp.os.ms-windows.programmer.win32
Subject	Found a undocumented way to have thread_local variables in DLLs
Date	2022-05-27 19:22 +0200
Organization	A noiseless patient Spider
Message-ID	<t6r1ca$aeu$1@dont-email.me> (permalink)

Cross-posted to 2 groups.

Show all headers | View raw

VC++ allows thread_local variables with VC++ only in executables and
not in DLLs. Thread local storage relies on that the global variable
__tls_index for which proper storage has to be allocated per thread.
This storage must be large enough to accomodate all thread_local and
__declspec(thread) variables declared in any function of the DLL.
Executables must have a hook unkown to me to notice any thread
creation and termination to allocate an deallocate that amount of
storage. DLLs have their DllMain which has a clean notification
mechanism when a DLL is being attached to a process, when a thread
is created or for already running theads while this DLL is being
loaded or for thread termination. With that it should be easy to
allocate a TLS index with DLL_PROCESS_ATTACH, deallocate it with
DLL_PROCESS_DETACH, allocate a proper amount of thread-specific
memory with DLL_THREAD_ATTACH and deallocate this memory with
DLL_THREAD_DETACH. The only thing that has to be documented with
that would be the variable __tls_index as well as a variable in
read-only memory which gives the amount of storage which needs
to be allocated with the total amount of storage needed for a
thread.
One issue with that is that C++ requires a thread_local object
to be constructed when the code first comes across the definition
of that variable. So there must be a boolean variable attached to
each objects not constructed by a constructor that says if that
object aleady has been constructed. The code allocating that
the thread local storage in DLL_THREAD_ATTACH could simply rely
on that this boolean variable is zero memory and zero the whole
block with or on allocation.

I implemented this in an undocumented way, but that's rather
simple:

#define _CRT_SECURE_NO_WARNINGS
#include <Windows.h>
#include <string>
#include <new>

using namespace std;

DWORD __tls_index;

BOOL APIENTRY DllMain( HMODULE hModule, DWORD dwReason, LPVOID lpReserved )
{
	switch( dwReason )
	{
	case DLL_PROCESS_ATTACH:
		::__tls_index = TlsAlloc();
		break;
	case DLL_THREAD_ATTACH:
		TlsSetValue( __tls_index, (void *)LocalAlloc( LMEM_ZEROINIT, 0x1000 ) );
		break;
	case DLL_THREAD_DETACH:
		LocalFree( (HLOCAL)TlsGetValue( __tls_index ) );
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}

extern "C"
__declspec(dllexport)
void myExport( char *out )
{
	thread_local string str( "hello world, hello world, hello world" );
	strcpy( out, str.c_str() );
}

The most unclean part of that solution is that I allocate an amount
of memory that's for sure larger than needed. A documented read-only
"variable" calculated and generated by the linker should be useful
here. The next undocumented issue that is more reliable is the image
-specific variable __tls__index which also would have to be documented.

Back to comp.lang.c++ | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-27 19:22 +0200
  Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-27 22:39 +0200
    Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-27 22:56 +0200
      Re: Found a undocumented way to have thread_local variables in DLLs "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-05-27 14:26 -0700
        Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-27 23:33 +0200
          Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-28 10:27 +0200
            Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-28 10:37 +0200
              Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-28 15:01 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-28 17:27 +0200
      Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-28 10:15 +0200
        Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-28 10:37 +0200
          Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-28 15:10 +0200
            Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-28 17:27 +0200
              Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-28 18:40 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-28 19:28 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-29 13:22 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 13:30 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-29 14:41 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 14:56 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs "R.Wieser" <address@not.available> - 2022-05-29 17:13 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Freethinker <freethinker@mymail.com> - 2022-05-29 15:09 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 17:38 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs muttley@dastardlyhq.com - 2022-05-29 15:47 +0000
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 18:17 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-29 18:56 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-29 19:21 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-29 19:26 +0200
                Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-30 11:30 +0200
  Re: Found a undocumented way to have thread_local variables in DLLs Mr Flibble <flibble@reddwarf.jmc> - 2022-05-27 21:48 +0100
    Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-27 23:01 +0200
  Re: Found a undocumented way to have thread_local variables in DLLs Paavo Helde <eesnimi@osa.pri.ee> - 2022-05-28 00:02 +0300
    Re: Found a undocumented way to have thread_local variables in DLLs Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-27 23:32 +0200

csiph-web