On Friday, 27 March 2015 at 12:15:03 UTC, Sönke Ludwig wrote:
Am 27.03.2015 um 11:11 schrieb Walter Bright:
On 3/27/2015 2:57 AM, Russel Winder via Digitalmars-d-announce
Aren't "green threads" now given the label fibres?
My understanding of fibers is they are all in one thread. Go's
threads can be in multiple threads, the same thread, and even
one thread to another.
And I think Vibe.d
has an implementation for these – but I do not know for
I don't know, either.
It has, that is more or less the original selling point. It
also keeps an internal thread pool where each thread has a
dynamic set of reusable fibers to execute tasks. Each fiber is
bound to a certain thread, though, and they have to, because
otherwise things like thread local storage or other thread
specific code (e.g. the classic OpenGL model, certain COM modes
etc.) would break.
Apart from these concerns, It's also not clear to me that
moving tasks between threads is necessarily an improvement.
There are certainly cases where that leads to a better
distribution across the cores, but in most scenarios the number
of concurrent tasks should be high enough to keep all cores
busy anyhow. There are also additional costs for moving fibers
(synchronization, cache misses).
I've always wondered whether thread-local fibers with a
stop-the-world (or at least part of the world) load balancer that
can move them would be a good model. You could get away without a
lot of synchronisation e.g. tls could be fixed-up from the
scheduler thread while all the others are stopped.
Perhaps there are good reasons why not, I don't know enough to