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

Subject: Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-05 14:33:27

On 09/05/2015 08:03 PM, Oliver Kowalke wrote:
> 2015-09-05 20:03 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]
> <mailto: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.

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>