Gary Willoughby: "Why Go's design is a disservice to intelligent programmers"

[John Colvin via Digitalmars-d-announce]

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 
>> wrote:
>>> Aren't "green threads" now given the label fibres?
>>
>> My understanding of fibers is they are all in one thread. Go's 
>> green
>> threads can be in multiple threads, the same thread, and even 
>> moved from
>> one thread to another.
>>
>>> And I think Vibe.d
>>> has an implementation for these – but I do not know for 
>>> certain.
>>
>> 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 
say...