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 11:46:47

2015-09-05 17:31 GMT+02:00 Hartmut Kaiser <hartmut.kaiser_at_[hidden]>:

>
> Hmmm, this is not what I would have expected, frankly. One of the main
> advantages of Fibers are their low creation/context switching/termination
> overhead. I would have expected for Fibers to be freely movable between
> kernel-threads (work-stealing!), even more so as you expose an interface
> conforming std::thread... If Fibers look like threads, they should behave
> accordingly.
>

but this is what C++ (incl. C++14) gives to us- compilers are free to
optimize
as they deserve.
I hope you agree that is not a restriction coming from boost.fiber

> I think that it is too over-constraining to inhibit moving Fibers between
> kernel-threads just to maintain NUMA awareness (not all architectures have
> those in the first place). The decision whether to move a Fiber or not
> should be entirely left to a scheduler/executor (which could confine a
> Fiber
> to a NUMA domain, for instance, if needed).
>

I agree but the compiler optimizations will break the application! Even if
it looks
like correct code!

> Also, it should be made very clear that the use of Fibers has certain
> implications on using TLS (in short - don't use TLS, but FLS instead)

user cod, executed by fibers, might contain TLS. especially if thrid-party
libraries
is used you might not aware if it uses TLS or not.
companies legacy code is not likely changed

> Thus the fact whether compilers cache the TLS or not is mostly irrelevant.
>

I strongly disagree!