Fiber is better than go's goroutine?

[Sean Kelly via Digitalmars-d]

On Sunday, 26 October 2014 at 20:47:47 UTC, Martin Nowak wrote:
>
> How do you want to tackle the integration of Fibers/Schedulers 
> and blocking APIs? That's the more important part of goroutines.
> http://blog.nindalf.com/how-goroutines-work/#goroutinesblocking

That will be tricky, since some of our blocking APIs are in 
Druntime (core.thread and core.sync) and std.concurrency is in 
Phobos.  I may have to add a yield() hook in Druntime that can be 
set by std concurrency.  But for now I think it's reasonable to 
say that std.concurrency will work as expected so long as you 
stick to Phobos functions and that Druntime simply operates at a 
lower level.

The real tricky part, which is something that even Go doesn't 
address as far as I know, is what to do about third-party APIs 
that block.  The easiest way around this is to launch threads 
that deal with these APIs in actual kernel threads instead of 
fibers, or try to make the scheduler smart enough to recognize 
that blocking is occurring (or more generally, that a given 
logical thread isn't playing nice) and move that fiber into a 
dedicated kernel thread automatically.  This latter approach 
seems entirely possible but will likely mean kernel calls to 
gather statistics regarding how long a given thread executes 
before yielding, etc.