Some GC and emulated TLS questions (GDC related)

[Joakim via Digitalmars-d]

On Sunday, 16 July 2017 at 12:37:26 UTC, Johannes Pfau wrote:
> Yes, probably the best solution for now is to reimplement GCC 
> style emutls with shared library support in druntime for all 
> compilers and forget about C/C++ TLS compatibility. Even if we 
> could get patches into libgcc it'd take years till all relevant 
> systems have been updated to new libgcc versions.

It might be worth doing anyway, considering the rise of GC 
languages like D and Go.

>> There is also this llvm implementation, available under 
>> permissive licenses and actually documented somewhat:
>> 
>> https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/emutls.c
>
> Unfortunately also not boost compatible, so we can't simply 
> port that code either, as far as I can see?

Yes, it can't simply be relicensed as Boost, even though the 
UIUC/MIT dual license it's under is very permissive, but each 
license has advertising and license text inclusion clauses that 
are not compatible with the Boost license.

On Sunday, 16 July 2017 at 14:10:45 UTC, Johannes Pfau wrote:
> Am Sun, 16 Jul 2017 14:48:04 +0200
> schrieb Iain Buclaw via Digitalmars-d 
> <digitalmars-d at puremagic.com>:
>
>> 
>> I sense a revert coming on...
>> 
>> https://github.com/D-Programming-GDC/GDC/commit/cf5e9e323b26d21a652bc2933dd886faba90281c
>> 
>> Iain.
>
> Correct, though more in a metaphorical sense ;-)
>
> Ideally, I'd want a boost licensed, high level D implementation 
> in core.thread. Instead of using __gthread get/setspecific, we 
> simply add a GC managed (i.e. plain stupid) void[][] _tlsVars 
> array to core.thread.Thread, use core.sync for locking and 
> core.atomic to manage array indices. With all the high-level 
> stuff we can reuse from druntime (resizing/reserving arrays) 
> such an implementation is probably < 100 LOC. Most importantly, 
> as we can't overwrite the functions in libgcc we'd also use 
> custom function names (__d_emutls_get_address).
>
> The one thing stopping me though is that I don't think I can 
> implement this and boost-license it now that I almost know the 
> libgcc implementation by heart...

Sounds like a worthwhile effort.  If it requires someone who's 
never looked at the libgcc implementation, you could try asking 
in the LDC forum or someone who's contributed to the GC.  Maybe 
Dmitry could whip this up for us?