Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #84287 > unrolled thread

Found a undocumented way to have thread_local variables in DLLs

Back to article view | Back to comp.lang.c++

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#84344

On 29.05.22 14:41, R.Wieser wrote:
> Bonita,
> 
>> Ok, you find a novice and don't understand the whole discussion.
> 
> What discussion ?    All you did was you showing off what you found.  I than
> made a few comments on it and you rejected all of them - often by not
> understanding anything about what I tried to explain.
> 
> In one instance I even followed it up with some pseudo-code to help you
> understand what I was talking about, but you didn't even bother to
> acknowledge it.   Ofcourse, that made me think that by it you understood you
> made a mistake the first time, but are simply not (yet) man enough to be
> honest about it ...
> 
> You're talking about a discussion that I didn't understand ?    There was no
> discussion.  That word implicates two (or more) people trying to understand
> each others viewpoints - even when they do not agree with each other - which
> I have not seen you do in any shape or form. :-(
> 
> Regards,
> Rudy Wieser
> 
> 
Rudy, why do you even bother? You know by now that Bonita is in serious 
need of professional psychiatric help.

I honestly believe you should keep your knowledge for people who want to 
read it.

Gruß

[toc] | [prev] | [next] | [standalone]

#84352

Am 29.05.2022 um 15:09 schrieb Freethinker:
> On 29.05.22 14:41, R.Wieser wrote:
>> Bonita,
>>
>>> Ok, you find a novice and don't understand the whole discussion.
>>
>> What discussion ?    All you did was you showing off what you found.  
>> I than
>> made a few comments on it and you rejected all of them - often by not
>> understanding anything about what I tried to explain.
>>
>> In one instance I even followed it up with some pseudo-code to help you
>> understand what I was talking about, but you didn't even bother to
>> acknowledge it.   Ofcourse, that made me think that by it you 
>> understood you
>> made a mistake the first time, but are simply not (yet) man enough to be
>> honest about it ...
>>
>> You're talking about a discussion that I didn't understand ?    There 
>> was no
>> discussion.  That word implicates two (or more) people trying to 
>> understand
>> each others viewpoints - even when they do not agree with each other - 
>> which
>> I have not seen you do in any shape or form. :-(
>>
>> Regards,
>> Rudy Wieser
>>
>>
> Rudy, why do you even bother? You know by now that Bonita is in serious 
> need of professional psychiatric help.

I don't need psychaitric help, I'm just intolerant with nerds.

[toc] | [prev] | [next] | [standalone]

#84353

On Sun, 29 May 2022 17:38:18 +0200
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Rudy, why do you even bother? You know by now that Bonita is in serious 
>> need of professional psychiatric help.
>
>I don't need psychaitric help, I'm just intolerant with nerds.

Says someone who posts 200+ lines of dense C++ rewrite of some system 
function apropos of nothing and presumably expects praise.

[toc] | [prev] | [next] | [standalone]

#84354

Am 29.05.2022 um 17:47 schrieb muttley@dastardlyhq.com:
> On Sun, 29 May 2022 17:38:18 +0200
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Rudy, why do you even bother? You know by now that Bonita is in serious
>>> need of professional psychiatric help.
>>
>> I don't need psychaitric help, I'm just intolerant with nerds.
> 
> Says someone who posts 200+ lines of dense C++ rewrite of some
> system function apropos of nothing and presumably expects praise.

I made the mistake to believe, that windows is still incapable of
TLS inside DLLs. I also posted this on Stack Overflow and most people
believed it also. So there are a lot of people who had thought this
is of any use and I thought it is useful for others.

[toc] | [prev] | [next] | [standalone]

#84358

On 29 May 2022 18:17, Bonita Montero wrote:
> Am 29.05.2022 um 17:47 schrieb muttley@dastardlyhq.com:
>> On Sun, 29 May 2022 17:38:18 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>> Rudy, why do you even bother? You know by now that Bonita is in serious
>>>> need of professional psychiatric help.
>>>
>>> I don't need psychaitric help, I'm just intolerant with nerds.
>>
>> Says someone who posts 200+ lines of dense C++ rewrite of some
>> system function apropos of nothing and presumably expects praise.
> 
> I made the mistake to believe, that windows is still incapable of
> TLS inside DLLs. I also posted this on Stack Overflow and most people
> believed it also. So there are a lot of people who had thought this
> is of any use and I thought it is useful for others.

Not sure of what you mean by "still".

I implemented general TLS in a C++ DLL that was called from Java (JNI), 
cirka 1998. That was for a Norwegian home banking system. As I recall 
one had to be very careful, but it worked.

Cheers,

- Alf

[toc] | [prev] | [next] | [standalone]

#84360

Am 29.05.2022 um 18:56 schrieb Alf P. Steinbach:
> On 29 May 2022 18:17, Bonita Montero wrote:
>> Am 29.05.2022 um 17:47 schrieb muttley@dastardlyhq.com:
>>> On Sun, 29 May 2022 17:38:18 +0200
>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> Rudy, why do you even bother? You know by now that Bonita is in 
>>>>> serious
>>>>> need of professional psychiatric help.
>>>>
>>>> I don't need psychaitric help, I'm just intolerant with nerds.
>>>
>>> Says someone who posts 200+ lines of dense C++ rewrite of some
>>> system function apropos of nothing and presumably expects praise.
>>
>> I made the mistake to believe, that windows is still incapable of
>> TLS inside DLLs. I also posted this on Stack Overflow and most people
>> believed it also. So there are a lot of people who had thought this
>> is of any use and I thought it is useful for others.
> 
> Not sure of what you mean by "still".

Windows Vista was the first Windows system which reliably supported
__declspec(thread) in dynamically loaded DLLs. I thought my information
was still up to date and most others on Stack Overflow also.

[toc] | [prev] | [next] | [standalone]

#84361

On 29 May 2022 19:21, Bonita Montero wrote:
> Am 29.05.2022 um 18:56 schrieb Alf P. Steinbach:
>> On 29 May 2022 18:17, Bonita Montero wrote:
>>> Am 29.05.2022 um 17:47 schrieb muttley@dastardlyhq.com:
>>>> On Sun, 29 May 2022 17:38:18 +0200
>>>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>>> Rudy, why do you even bother? You know by now that Bonita is in 
>>>>>> serious
>>>>>> need of professional psychiatric help.
>>>>>
>>>>> I don't need psychaitric help, I'm just intolerant with nerds.
>>>>
>>>> Says someone who posts 200+ lines of dense C++ rewrite of some
>>>> system function apropos of nothing and presumably expects praise.
>>>
>>> I made the mistake to believe, that windows is still incapable of
>>> TLS inside DLLs. I also posted this on Stack Overflow and most people
>>> believed it also. So there are a lot of people who had thought this
>>> is of any use and I thought it is useful for others.
>>
>> Not sure of what you mean by "still".
> 
> Windows Vista was the first Windows system which reliably supported
> __declspec(thread) in dynamically loaded DLLs. I thought my information
> was still up to date and most others on Stack Overflow also.

May be some confusion about MSVC language support and Windows API here.

Microsoft has almost /encouraged/ such confusion, e.g. with SEH 
exception handling, which appeared to be documented but which 
documentation was really only about the MSVC binding. Poor Borland had 
to do undocumented stuff for their SEH support. Makes Microsoft able to 
implicitly say, look, the others' products do not support all the 
features we support, we're the only ones providing full support, yah.

Cheers,

- Alf

[toc] | [prev] | [next] | [standalone]

#84376

> Microsoft has almost /encouraged/ such confusion, e.g. with SEH 
> exception handling, which appeared to be documented but which 
> documentation was really only about the MSVC binding. ...


I'Ve got no problems to use SEH with clang-cl, the mostly MSVC
-compatible version of clang.
I've uses SEH 1993 with Windows NT 3.1 and I has no issues with
that.

[toc] | [prev] | [next] | [standalone]

#84291

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

[toc] | [prev] | [next] | [standalone]

#84294

> I am using thead_local in DLLs without this hack; are you
> aware that Microsoft fixed an issue regarding this in VS2019?

You're right, I relied on outdated information.
Much effort for nothing.

[toc] | [prev] | [next] | [standalone]

#84295

27.05.2022 20:22 Bonita Montero kirjutas:
> VC++ allows thread_local variables with VC++ only in executables and
> not in DLLs.

In general, thread_local in DLL-s with MSVC++ is working fine. I have 
not seen any issues in production for several years.

There are some limitations, one cannot dll-export a thread_local 
variable. But why would one want to do that?

There are also mentions in MS documentation that thread local variables 
might not work so well before Windows Vista. But who remembers those times?

There are also problems that thread_local storage is initialized in 
DllMain and so might not be properly initialized when accessed in old 
threads which existed before dynamically loading the DLL. But it looks 
like your solution does no better, it's using the same DllMain mechanism 
and looks pretty simplistic.

If you insist you have solved a problem then you should first 
demonstrate the problem, then show how your solution fixes that.

[toc] | [prev] | [next] | [standalone]

#84298

Am 27.05.2022 um 23:02 schrieb Paavo Helde:
> 27.05.2022 20:22 Bonita Montero kirjutas:
>> VC++ allows thread_local variables with VC++ only in executables and
>> not in DLLs.
> 
> In general, thread_local in DLL-s with MSVC++ is working fine. I have 
> not seen any issues in production for several years.

Yes, I noticed this also. I already said that to MrFibble (idiotic
pseudonym), but then I thought that I never knew that there were
times when this doesn't happen. The issue was simple that my DLL
injection code doesn't allow thread_local variables for the DLL
injected into a foreign process. And then I've seen that manual
thread-local storage with GetTls() ... is documented very well
and thought that there must be a general drawback of thread local
storage in DLLs.

> There are some limitations, one cannot dll-export a thread_local 
> variable. But why would one want to do that?

Limitaton ? What do you want ? A GetProcAddess() (not only used
for callable code but also for arbitrary global variables) with
an attached thread-id to get the right version ???

> There are also mentions in MS documentation that thread local variables 
> might not work so well before Windows Vista. But who remembers those times?

Ooooh, I was yet partitially right, so my above corrections weren't
absolutely necessary. Before Vista your code using thread local storage
could crash when the library is loaded dynamically.

> There are also problems that thread_local storage is initialized in 
> DllMain ...

I think there are no reasons to have thread local storage in DllMain.

> If you insist you have solved a problem then you should first 
> demonstrate the problem, then show how your solution fixes that.

At least before Vista my code solves a problem because it does
the whole thread local storage initialization on its own.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web