Is D right for me?

[Jacob Carlborg]

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