Phobos Action Items

[ZombineDev via Digitalmars-d]

On Sunday, 19 June 2016 at 06:28:45 UTC, deadalnix wrote:
> 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.

I agree. BTW, what do you think about improving the compiler's 
understanding of Fibers (AFAIU they're purely a runtime thing), 
so e.g. they're usable at CTFE. See this for more details:

http://lists.llvm.org/pipermail/llvm-dev/2016-June/100838.html