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.
