2015-09-05 17:31 GMT+02:00 Hartmut Kaiser
Hmmm, this is not what I would have expected, frankly. One of the main advantages of Fibers are their low creation/context switching/termination overhead. I would have expected for Fibers to be freely movable between kernel-threads (work-stealing!), even more so as you expose an interface conforming std::thread... If Fibers look like threads, they should behave accordingly.
but this is what C++ (incl. C++14) gives to us- compilers are free to optimize as they deserve. I hope you agree that is not a restriction coming from boost.fiber
I think that it is too over-constraining to inhibit moving Fibers between kernel-threads just to maintain NUMA awareness (not all architectures have those in the first place). The decision whether to move a Fiber or not should be entirely left to a scheduler/executor (which could confine a Fiber to a NUMA domain, for instance, if needed).
I agree but the compiler optimizations will break the application! Even if it looks like correct code!
Also, it should be made very clear that the use of Fibers has certain implications on using TLS (in short - don't use TLS, but FLS instead)
user cod, executed by fibers, might contain TLS. especially if thrid-party libraries is used you might not aware if it uses TLS or not. companies legacy code is not likely changed
Thus the fact whether compilers cache the TLS or not is mostly irrelevant.
I strongly disagree!