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
