IIRC it was used prior to 2.030. In the spec, it is in the keyword list, and it's also listed in the "Migrating to shared" article. That's all. There are a small number of uses of it in the DMD test suite.

Is it still valid? Is it useful? Or has everyone forgotten that it still exists?

On Nov 14, 2012, at 6:26 AM, Don Clugston <dac@nospam.com> wrote:

> IIRC it was used prior to 2.030. In the spec, it is in the keyword list, and it's also listed in the "Migrating to shared" article. That's all. There are a small number of uses of it in the DMD test suite.
> 
> Is it still valid? Is it useful? Or has everyone forgotten that it still exists?

I think __thread was for explicit TLS before TLS became the default.  I don't see a continued use for it.

On 11/14/2012 12:06 PM, Sean Kelly wrote:
> On Nov 14, 2012, at 6:26 AM, Don Clugston <dac@nospam.com> wrote:
>
>> IIRC it was used prior to 2.030. In the spec, it is in the keyword list,
>> and it's also listed in the "Migrating to shared" article. That's all.
>> There are a small number of uses of it in the DMD test suite.
>>
>> Is it still valid? Is it useful? Or has everyone forgotten that it still
>> exists?
>
> I think __thread was for explicit TLS before TLS became the default.  I don't
> see a continued use for it.
>

Sean's right.

On 14/11/12 23:16, Walter Bright wrote:
> On 11/14/2012 12:06 PM, Sean Kelly wrote:
>> On Nov 14, 2012, at 6:26 AM, Don Clugston <dac@nospam.com> wrote:
>>
>>> IIRC it was used prior to 2.030. In the spec, it is in the keyword list,
>>> and it's also listed in the "Migrating to shared" article. That's all.
>>> There are a small number of uses of it in the DMD test suite.
>>>
>>> Is it still valid? Is it useful? Or has everyone forgotten that it still
>>> exists?
>>
>> I think __thread was for explicit TLS before TLS became the default.
>> I don't
>> see a continued use for it.
>>
>
> Sean's right.

Good, that's what I thought. Lets remove it from the spec, and deprecate it. There is probably no extant code that uses it, outside of the test suite.

However, there is one case in the test suite which is unclear to me:

extern(C) __thread int x;

Is there any other way to do this?

On 2012-11-15 11:28, Don Clugston wrote:

> However, there is one case in the test suite which is unclear to me:
>
> extern(C) __thread int x;
>
> Is there any other way to do this?

extern (C) int x;

"extern(C)" doesn't make it global.

-- 
/Jacob Carlborg

On 11/15/2012 2:28 AM, Don Clugston wrote:
> However, there is one case in the test suite which is unclear to me:
>
> extern(C) __thread int x;
>
> Is there any other way to do this?

extern(C) int x;

On 15/11/12 11:54, Walter Bright wrote:
> On 11/15/2012 2:28 AM, Don Clugston wrote:
>> However, there is one case in the test suite which is unclear to me:
>>
>> extern(C) __thread int x;
>>
>> Is there any other way to do this?
>
> extern(C) int x;
>

What about extern(C) variables which are not thread local?
(which I think would be the normal case).
Then from a C header,

extern(C) int x;

must become:

extern(C) __gshared int x;

in D. It's a very rare case, I guess, but it's one of those situations where D code silently has different behaviour from identical C code.

On 15-11-2012 15:42, Don Clugston wrote:
> On 15/11/12 11:54, Walter Bright wrote:
>> On 11/15/2012 2:28 AM, Don Clugston wrote:
>>> However, there is one case in the test suite which is unclear to me:
>>>
>>> extern(C) __thread int x;
>>>
>>> Is there any other way to do this?
>>
>> extern(C) int x;
>>
>
> What about extern(C) variables which are not thread local?
> (which I think would be the normal case).
> Then from a C header,
>
> extern(C) int x;
>
> must become:
>
> extern(C) __gshared int x;
>
> in D. It's a very rare case, I guess, but it's one of those situations
> where D code silently has different behaviour from identical C code.

I think most people are aware of this 'quirk' from what I've seen in binding projects, so it's probably not a big deal.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On 11/15/2012 6:42 AM, Don Clugston wrote:
> On 15/11/12 11:54, Walter Bright wrote:
>> On 11/15/2012 2:28 AM, Don Clugston wrote:
>>> However, there is one case in the test suite which is unclear to me:
>>>
>>> extern(C) __thread int x;
>>>
>>> Is there any other way to do this?
>>
>> extern(C) int x;
>>
>
> What about extern(C) variables which are not thread local?
> (which I think would be the normal case).
> Then from a C header,
>
> extern(C) int x;
>
> must become:
>
> extern(C) __gshared int x;

That's right. extern(C) doesn't change the storage class.

> in D. It's a very rare case, I guess, but it's one of those situations where D
> code silently has different behaviour from identical C code.

On 11/15/2012 6:46 AM, Alex Rønne Petersen wrote:
> I think most people are aware of this 'quirk' from what I've seen in binding
> projects, so it's probably not a big deal.


Also, remember that C code can now have thread local globals, too. Both are expressible in D, it's just that the default is reversed.