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@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?
