On Jul 18, 2013, at 11:38 AM, "Matt" <[email protected]> wrote:
> On Thursday, 18 July 2013 at 17:55:36 UTC, Sean Kelly wrote: >> Not as such. I'd like to make Fibers each have their own message queue in >> std.concurrency, but that means making TLS work at the fiber level, which is >> tricky. >> >> I think there is value in the CSP model (ie. channels), but haven't done >> anything about it in terms of library work. > > From what I've read about Fibers, it seems they are more similar to what I'm > looking for (a post on stackoverflow implied they are similar to Erlang's > implementation of lightweight tasks). Does this mean to say they are similar > to the tasks provided by std.parallelism? 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.
