2015-09-05 17:31 GMT+02:00 Hartmut Kaiser <hartmut.kaiser@gmail.com>:

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!