On 2010-10-14 20:12, Walter Bright wrote:
Jacob Carlborg wrote:
On 2010-10-13 20:18, Walter Bright wrote:
Furthermore, OSX has no documented way to allocate TLS
static data in the object file. I spent considerable effort figuring out
a way to do this and get around the numerous bugs in the OSX linker that
tried to stop me.
I just read a bit about how TLS is implemented on linux, just of
curiosity what was the problem, the linker, runtime, loader or all? On
linux the static TLS data is put in the the object file like any other
data. The only difference is it has a different name of the
section/segment and an additional flag. Then of course the linker,
runtime and loader know about these sections and make any necessary
initializations when the application loads.
The linker, runtime, and loader do not know about any TLS sections under
OSX, and do not do any necessary initializations. The linker bugs were
because it behaved erratically when laying out named sections that were
not the usual sections emitted by gcc.
Can't the necessary initializations be done early in the start up
process of the D runtime or is it already to late when application
receives control? Since you have non-standard sections in the object
file I assume you solved it.
Anyhow, the source is here:
http://www.dsource.org/projects/druntime/browser/trunk/src/core/thread.d
and the function you're interested in is ___tls_get_addr. You're welcome
to make improvements to it.
That doesn't seem to be a lot of code to optimize, is Thread.getThis()
slow?
I've already been 'round the block on that code a few times. If you want
to have a go at it, perhaps I missed something and you'll see it.
Thread.getThis() calls pthread_getspecific which is just three
instructions on Mac OS X, so I guess that's not why it's so slow. The
only thing I can think of is first moving the if statement into the
assert and then trying to inline as much of the function calls.
--
/Jacob Carlborg
