Re: Found a undocumented way to have thread_local variables in DLLs

From	"R.Wieser" <address@not.available>
Newsgroups	comp.lang.c++, comp.os.ms-windows.programmer.win32
Subject	Re: Found a undocumented way to have thread_local variables in DLLs
Date	2022-05-27 22:39 +0200
Organization	Aioe.org NNTP Server
Message-ID	<t6rcuk$1sq1$1@gioia.aioe.org> (permalink)
References	<t6r1ca$aeu$1@dont-email.me>

Cross-posted to 2 groups.

Show all headers | View raw

Bonita,

> VC++ allows thread_local variables with VC++ only in executables and not 
> in DLLs.

Thats odd, as they seem to be purposely created for DLL usage ...

https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-tlsalloc

> Thread local storage relies on that the global variable __tls_index for 
> which proper storage has to be allocated per thread.

I'm not sure you are aware of how different that can be read than from how 
you ment it ...

Luckily you again explain it a bit lower, and with a bit more info to go on 
: "it should be easy to allocate a TLS index with DLL_PROCESS_ATTACH,"

> This storage must be large enough to accomodate all thread_local
>  and __declspec(thread) variables declared in any function of the DLL.

You did not yet explain what "this storage" is, but further on I see you 
allocate some memory and put its pointer/handle into Tls storage.   I'm 
assuming that that is what you are talking about.

> Executables must have a hook unkown to me to notice any thread
> creation and termination to allocate an deallocate that amount of
> storage.

No hook needed :  When a process creates a thread it executes the same way 
as a function : it starts at the top and exits at the bottom.   That means 
that the threads codeblock can just allocate that memory at the top, and 
deallocate it at the bottom, just before exiting.

>The only thing that has to be documented with
> that would be the variable __tls_index

Yup.

> 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.

Shouldn't you already know that when you create that DLL ?    IOW, a 
constant set in the DLLs sourcecode should cover it.

> 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.

If your program comes across the Tls storage initialisation code multiple 
times you're probably doing something wrong.   If all is well you only 
encounter it at the top (of the program or the DLL), and than never again.

But if you have that problem, why not use the variable that stores the index 
as the "boolean" itself.  Just initialize it with the TLS_OUT_OF_INDEXES 
value.  If you see that it means you need to run TlsAlloc.  If that same 
value is returned by TlsAlloc it means you have a big problem, and need to 
abort.   IOW, after having run TlsAlloc once you either abort or the 
variable storing the index has changed.

> The most unclean part of that solution is that I allocate an amount
> of memory that's for sure larger than needed.

As mentioned in the above, if you are writing the DLLs thread you should be 
able to know how much thread-global storage you need for it.

Regards,
Rudy Wieser

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