TLF = thread local functions

[Dicebot]

On Friday, 24 January 2014 at 10:43:05 UTC, Stanislav Blinov 
wrote:
>> It actually should not even compile without explicit casts. I 
>> guess yet another delegate qualifier bug.
>
> Why shouldn't it compile? Safe spawner (std.concurrency.spawn) 
> does not accept delegates. Unsafe one (core.thread.Thread) 
> does. I wouldn't consider it a bug since in the context of one 
> thread it's pretty much a feature :)
> But I agree that some special syntax for threading and 
> otherwise restricting sharing would be great. Maybe another set 
> of parentheses?

D type system is supposed to guarantee that you never ever can 
get pointer/reference to data that is not stored in your own TLS 
(including stack) unless it is marked as shared (immutable / 
__gshared are in shared category).

By allowing to spawn thread with a delegate which has context 
pointer not qualified as shared you break that type system sanity 
rule.

Multithreading / concurrency in D is quite different from C++.

>>> Um, duh, but in d data is already TLS.
>>
>> 1) not necessarily, is is only default
>>
>> 2) "using TLS data" usually implies "using _own_ TLS data" as 
>> you shouldn't be able to get reference to TLS of other thread 
>> without dirty hacks (it breaks basic type system assumptions)
>
> In my understanding delegates are pretty much unique at that. 
> Probably because they were redesigned like that since D1, but 
> never were taken one step further towards multithreading.

Delegates unique in a sense that they often erase type qualifiers 
for the context because of rather hacky current implementation. 
All such cases are bugs that contradict language spec, there is 
nothing intentional about it.

There are no legal exceptions to the rule "all shared data must 
be shared".