On Apr 19, 2012, at 10:55 PM, Kapps wrote: > 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.
There wouldn't me much of a performance hit, mostly an additional allocation and a bitcopy when creating a Fiber. It's more that making this work on platforms with built-in TLS could be quite tricky.
