Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13

On 09/05/2015 08:03 PM, Oliver Kowalke wrote:

2015-09-05 20:03 GMT+02:00 Thomas Heller mailto: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.

I don't think that is what Hartmut or I wanted to suggest. What should be possible though is to implement something like HPX on top of Boost.Fiber.

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.

Oh, HPX has a fully conformant implementation of something std::thread-like. We also support non stealing schedulers, but that's not important. What I think is important though is that Boost.Fiber shouldn't unnecessarily restrict its usefulness due to some overly restrictive usage requirements.

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

I currently don't see why this design wouldn't allow to have threads migrated, even if the TLS value is cached, it should still be valid, right? In that case you would have something like a benign "race".

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

I understand and I certainly see the advantages of that design.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users