Steven Schveighoffer <schvei...@yahoo.com> writes: > On 6/1/15 11:40 AM, Dan Olson wrote: >> "Dicebot" <pub...@dicebot.lv> writes: >> >>> - Moving fibers between threads (though there is some hope that Liran >>> managed to convince Walter it is a bad idea) >> >> I am interesting in this one. What was the decision, that Fibers should >> or should not be allowed to migrate between threads? Is the discussion >> in one of the recorded talks? >> > > Walter said that fibers must be movable between threads, it was part > of the AMA I think (day 1 final talk).
Just listened to it. I would be interested to know applications where migrating Fibers across threads is a good thing. I can imagine server load balancing over cores. What else? The issue I've been tripped up by with migrating Fibers is that compiler backends like LLVM and GCC do some nice optimizations with thread-locals on some targets that lead to incorrect code when a Fiber yields and comes back on a different thread. To get it right, the compiler would have to assume that any function call could return on a different thread. The solutions I can think of today are to: not optimize (not a good solution), or have a special compiler switch to not optimize TLS (not available in backend), or ensure Fibers don't access TLS vars (not sure how that could be done except by being careful), or don't migrate. Inlining makes being careful difficult because a function call before and after a yield may access the same TLS var, and compiler then decides to cache the TLS address in a register. I have been prototyping a Fiber check that throws an exception on targets with this issue, and the developer can override it by setting a Fiber property, after promising to be careful. http://forum.dlang.org/thread/onkyxucuuthaqxxbk...@forum.dlang.org#post-m2d223wqa0.fsf:40comcast.net