On Friday, 20 April 2012 at 05:08:13 UTC, Sean Kelly wrote:
I've thought about giving fibers their own TLS so D could have "real" user space threads. It would allow us to make the thread count in apps substantially higher if everything were a fiber and std.concurrency receive, for example, performed a context switch instead of blocking.
Would this cause a noticeable performance hit? One of the most important things is that fibers are incredibly cheap. For example, in my web server I'd like to implement being able to use a fiber for each request that has to wait on an asynchronous operation (aka, a database call or file read) to allow anothe request to be proecssed during the wait. If fibers had a noticeable performance hit (such as if they had to run per-thread static constructors to initialize things like TLS data), this would not work and I'd have to resort to essentially reimplementing fibers.
