On Jul 19, 2013, at 12:48 AM, deadalnix <[email protected]> wrote: > 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.
I think this would most likely happen within std.concurrency, with the context switch occurring on send/receive.
