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.
