This week's experiment build gdc with tls disabled.
Iain Buclaw
ibuclaw at gdcproject.org
Wed Dec 18 09:36:53 PST 2013
On 18 December 2013 15:39, Johannes Pfau <nospam at example.com> wrote:
> Am Tue, 17 Dec 2013 21:12:41 +0100
> schrieb "David Nadlinger" <code at klickverbot.at>:
>
>> On Tuesday, 17 December 2013 at 20:07:41 UTC, Iain Buclaw wrote:
>> > The hidden subtext that you didn't understand being, I'm
>> > holding back on Martin's patches for now.
>>
>> That subtext isn't exactly hidden, given the first sentence in
>> your first post. ;)
>>
>> Do you have a plan yet regarding how to implement module
>> discovery for shared libraries? Would be a good idea to
>> coordinate efforts and find a solution that works for all the
>> backends, as Martin has been suggesting as well.
>>
>> David
>
> I hope I'm not talking bullshit here as I'm not 100% sure what's meant
> with 'module discovery'.
>
I'm not so sure about 'module discovery' either. At least, in
emulated TLS, it has a completely different concept - each thread has
a dynamically allocated range (effectively, a void**[] on the heap
that gets destroyed upon thread termination) which is shared amongst
all modules / loaded libraries in D for the duration of the thread.
So when it comes to calling getTLSRange() - what is effectively
happening is:
void**[] tlsarray = gthread_getspecific(emutls_key);
return cast(void[]) tlsarray[0 .. $];
What I'm hoping is that whatever Martin has done, it is compatible
with this way of doing things...
More information about the D.gnu
mailing list