Phobos Action Items

[deadalnix via Digitalmars-d]

On Sunday, 19 June 2016 at 05:37:01 UTC, Walter Bright wrote:
> On 6/18/2016 10:22 PM, Suliman wrote:
>>> 8. create a greenthreads module that works like Goroutines
>>
>> But we already have fibers, I thought that they are same with 
>> Goroutines
>>
>
> Fibers are thread local. Goroutines are distributed among 
> fibers and threads, and can switch from one thread to another.

Alright. What is the goal here ?

First, Fiber are doing some synchronized work. This must go. They 
can't be exchanged across thread safely so this is only make 
performance worse without any benefit.

Second, while go move goroutine from one thread to another, the 
go scheduler goes to great length to avoid doing it. There is all 
kind of bad side effects coming from this and you don't want 
them. HHVM does not move requests from one thread to another.

It is to be noted that go to not provide any control over 
scheduling, while D does, doesn't have thread local storage and 
the type system doesn't provide any sharing constraints.

This is important because we do. If we want to make that work, 
there are implications. First, it become impossible to cache the 
TLS segment address across function calls as any function call 
can mean the thread has changed. Even with that deoptimization 
(that all code will need to pay, not only the code using these 
goroutines) that means the type system is now completely broken. 
Any goroutine can take the address of a thread local, store it on 
the stack and voila, it is now shared across threads. So that 
means you need in addition DIP30 or something alike to make sure 
that the only things passed to the goroutine is shared. In 
addition, you want to make sure these do not touch the TLS, so 
you either need some kind of new attribute, like pure_tls, or 
just make them pure altogether (which would reduce their utility 
greatly).

TL;DR : It sucks, there are all kind of bad side effects. The 
only reason go does it, is because they goroutine everything and 
can only have an adaptive strategy as this is done in the runtime.

Now on the rant. We don't need more stuff. We have plenty of 
stuff. We have plenty of unfinished stuff and this is what we 
should focus on. We have plenty of stuff that try to be 2 things 
at once and does both badly. We don't need anymore of this.

Just remove all synchronization from fiber and be done with it.