TLF = thread local functions

[Stanislav Blinov]

On Friday, 24 January 2014 at 11:00:42 UTC, Dicebot wrote:

> 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).

Agreed.

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

Agreed again. AFAIK, that was the exact reasoning behind 
restricting std.concurrency to not allow delegates as thread 
functions or message types.

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

With this I cannot completely agree. Granted, we have "shared" 
qualifier and by-default-TLS static data. Oh, and built-in 
monitors + synchronized methods (which are of dubious value at 
best). In that, D differs. But the bare bones of concurrency 
still are the same. Access to shared data still has to be 
manually synchronized somehow (locks, atomics, cas, you name it). 
Threads still have to be spawned and joined as necessary.

Ok, we have some of the boilerplate removed thanks to 
std.concurrency and std.parallelism, but that's just library 
solutions, not unlike those that exist for C++. I.e. there's 
nothing in the language that says "use that!".

And sadly, when threading is concerned, purity doesn't help much 
because of the "weak purity" concept.

> 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".

Agreed.

Oh, speaking of holes in the type system. Synchronization 
primitives like Mutex, Condition, etc. (which should be de-facto 
shared) aren't qualified as shared. Do you know if it's 
intentional or?..