Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #84305
| 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-28 10:15 +0200 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <t6smd4$a7a$1@gioia.aioe.org> (permalink) |
| References | <t6r1ca$aeu$1@dont-email.me> <t6rcuk$1sq1$1@gioia.aioe.org> <t6rdsv$5qu$1@dont-email.me> |
Cross-posted to 2 groups.
Bonita,
>> You did not yet explain what "this storage" is, ...
>
> Ok, you don't know it.
Not at the moment you mentioned it, no. IOW, the order in which you
explained yourself left a bit to be desired.
>> Shouldn't you already know that when you create that DLL ?
>> IOW, a constant set in the DLLs sourcecode should cover it.
>
> DLLs don't support TLS.
Whut? You have even included code showing they do.
>> If your program comes across the Tls storage initialisation code multiple
>> times you're probably doing something wrong. ...
>
> This doesn't happen since the operating system does DLL_THREAD
> _ATTACH calls only once for each thread.
In that case, why did you mention the need for a boolean ?
>> But if you have that problem, why not use the variable that stores the
>> index
>> as the "boolean" itself.
>
> Because TLS does need much more information per thread than s single
> boolean.
Read what you quoted again. Notice both that I said "why not *USE*" as well
as me quoting the "boolean" word, giving an indication that its not actually
a boolean but something else. But read on.
>> Just initialize it with the TLS_OUT_OF_INDEXES value.
>
> *facpalm*
> Are you trolling ?
Yes, that must be it. On the other hand, you just might not have
understood what I tried to offer you :
Create the (global) __tls_index variable initialized with the value
TLS_OUT_OF_INDEXES. Than use the following:
pseudo-code:
- - - - -
if __tls_index == TLS_OUT_OF_INDEXES {
__tls_index =TlsAlloc()
if __tls_index == TLS_OUT_OF_INDEXES {
Houston, we have a problem and need to abort.
}
- - - - -
At this point you have either aborted, or the __tls_index variable contains
a value different from TLS_OUT_OF_INDEXES, meaning that the next time around
the Tls slot intialisation (and its result checking) will be skipped.
>> 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.
>
> The DLL itself determines how much thread-local storage has to
> be allocated, it's the same for all targets.
You're confusing me : What is the below than all about ? :
[quote]
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.
[/quote]
Either you do /not/ know how much you need to allocate and it needs to be
gotten from where you stored it somewhere in your DLL (but where than do you
get the number from you have stored there ?), or you /do/ know, and no such
storage is needed. Not both.
Remark :
My previous message as well as the current one have been written in an
attempt to give you some hints and further possibly worth-to-know info.
If you think you should be nasty about it I think I will just leave you to
your own devices.
Though congrats for figuring out how to use Tls in DLLs (even though that is
what it was ment for in the first place). I know from experience how
difficult the "how the h*ll does that work ?" sometimes is.
Regards,
Rudy Wieser
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