On Apr 20, 2012, at 1:42 PM, Jameson Ernst wrote: > On Friday, 20 April 2012 at 18:09:37 UTC, Sean Kelly wrote: >> On Apr 20, 2012, at 10:59 AM, Andrew Lauritzen wrote: >> >>> On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote: >>>> 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. >>> Note that this would somewhat sabotage their usefulness as coroutines, >>> depending on how it was implemented. That's not to say the idea isn't good >>> (but I'd frame it more like "tasks"; see Thread Building Blocks or >>> similar), but fibers/coroutines as they stand now are useful so I'd hate to >>> see that capability lost. >> >> Ah, coroutines would actually want to share TLS with the executing thread? >> That's good to know. > > Yeah, I think there's a subtlety at play here, but it's an important one. In > most languages and environments, a thread of execution and a call stack are > conflated into a single entity. I think what Andrew and I are driving at is > that we'd like them to be orthogonal concepts. > > A "thread" is merely a lane of execution, and that lane can play host to any > call-stack "fiber" context we'd like it to. For this reason, it's important > that fibers not be bound to the thread that initially created them. Mono > implemented a continuation system, but the stack context is tied to the > thread that spawned it, which is frustrating and prevents efficient task > pooling.
The weird thing in D is that static data is thread-local by default, so moving a fiber between threads would mean the value of statics would change between calls. I had thought that by giving each fiber its own TLS space the programming model would be more predictable, but I can see how the current behavior may actually be desirable in some instances. I wonder if there's any value in having a child of Fiber that has its own TLS, call it CoopThread or whatever. For the record, there's absolutely nothing preventing you from moving a fiber across threads in Druntime. It's absolutely legal behavior, despite the potential weirdness with statics.
