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

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-05 14:03:08

2015-09-05 20:03 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:

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