Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #84291
| From | Mr Flibble <flibble@reddwarf.jmc> |
|---|---|
| Newsgroups | comp.lang.c++, comp.os.ms-windows.programmer.win32 |
| Subject | Re: Found a undocumented way to have thread_local variables in DLLs |
| Message-ID | <20220527214849.000044ab@reddwarf.jmc> (permalink) |
| References | <t6r1ca$aeu$1@dont-email.me> |
| Organization | Jupiter Mining Corp |
| Date | 2022-05-27 21:48 +0100 |
Cross-posted to 2 groups.
On Fri, 27 May 2022 19:22:28 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
> 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.
>
I am using thead_local in DLLs without this hack; are you aware that
Microsoft fixed an issue regarding this in VS2019?
/Flibble
Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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