2015-09-05 20:03 GMT+02:00 Thomas Heller <thom.heller@gmail.com>:

wouldn't that be an alternative and reasonable strategy?

 Absolutely

it seams to me that it makes not sense that boost.fiber tries to re-implement HPX's strategy.
if a user requires migration of fibers he can use HPX, if the user has to use TLS in its code (fiber-fn) and
wants an std::thread-like API (== this_fiber::yield(), mutex, condition_variable ...) he can choose
boost.fiber.

at the moment I don't see a possibility to eliminate the TLS-requirement for fiber_manager

Yes, we have a slightly different approach. All HPX Fibers are called from within a scheduling loop. A yield is therefor just a context switch back to the scheduling loop, no lookup required.

so HPX's scheudling loop runs in the main-context (e.g. main() or thread-fn) - in contrast boost.fiber handles the main-fiber (main() or thread-fn) as a fiber too.
e.g. the main-fiber can be suspended, stored, resumed int the same way as ordinary fibers (ordinary fibers == nedd to allocate fiber-stack, created via fiber ctor).
thus the difference between main-fiber and ordinary fibers (created via fiber ctor) is that the main-fiber has already a stack (provided and assigned by the os) assigned