Channels for tasks?

[deadalnix]

On Thursday, 18 July 2013 at 19:08:25 UTC, Sean Kelly wrote:
> Functionally, fibers are coroutines.  They have their own stack 
> and execute within the context of the calling thread.  Most 
> languages that scale to thousands or millions of concurrent 
> threads/processes use fibers (often called "green threads" in 
> this context) to pull it off.  The obstacle for D is that 
> global data is thread-local by default, so if we were to use 
> fibers in the back-end to allow the creation of a large number 
> of "threads", fibers would basically need their own TLS to 
> avoid breaking code.  We already do in-library TLS for OSX and 
> so it shouldn't be terribly difficult to use this logic for 
> fibers, but things get tricky once you consider dynamic 
> libraries.  It really should happen at some point though, for 
> std.concurrency to operate at its full potential.

My take is that we should keep fibers as they are. But change 
Thread (as the class in the runtime) to be Fibers with FLS and 
then let the runtime operate system thread and schedule Thread on 
them.

The read system thread can still be provided in some dark corner 
of the standard lib or runtime.