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.
From this perspective there wouldn't be a need for Boost.Fiber in the first place as all of this (yield, mutex, condvar, etc.) is implemented in HPX already.
at the moment I don't see a possibility to eliminate the TLS-requirement for fiber_manager
Too bad, I was hoping we could reuse it in HPX :/
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
HPX has no 'main' context. It requires for the user to supply a special hpx_main() function which is used as the application's main() and which is already a fiber. // This is executed as the first fiber int hpx_main(int argc, char* argv) { // ...your app goes here... // signal end of execution to the runtime return hpx::finalize(); } int main(int argc, char* argv) { // start runtime and wait for it to finish return hpx::init(argc, argv); } HTH Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu