D for Game Development

[Johannes Pfau via Digitalmars-d]

Am Sun, 9 Aug 2015 01:05:35 -0700
schrieb Walter Bright <newshound2 at digitalmars.com>:

> I don't understand your question. On Linux, TLS data is inserted into
> the same section that gcc puts it. On OSX, where gcc didn't support
> TLS, dmd did create it into a data segment. Every time a new thread
> was created, druntime would malloc a chunk of data, and copy that
> data segment into it to initialize it. Then it would save a pointer
> to the malloced data in the thread data structure.
> 
> Accessing the OSX TLS involved finding the thread data structure for
> the current thread, and getting the pointer to the TLS malloced data,
> and adding the offset of the symbol to it.
> 

Do you support shared libraries on OSX with that emulated TLS system
for all use cases? What if library A want to access a exported TLS
variable in library B? How do you:

1) Find the library the imported symbol is exported from (libraryB)
2) Find the TLS block for that library
3) Find the offset in that TLS block 

> The only reason a new data section was required was so that all the
> TLS data from all the object modules would be adjacent. It's the only
> way to do it.
> 

That statement is too broad to be true ;-) GCC's emulated TLS doesn't
have adjacent memory for TLS variables and it works fine with D
(and the GC). It is a little bit slower than if we had adjacent memory.
OTOH this approach works with all kinds of shared libraries and
requires very little system specific code (only need some pthread tls
mechanism). And it is compatible with GCCs emulated TLS, so you can
even have extern TLS variables shared between C and D with emutls.