Boost logo

Boost :

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-04 22:17:36


2015-09-04 22:33 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:

> Ok makes sense. So on a non-fiber context this is essentially a noop?

yes, I'm referring to a fiber-context

> Might be a good idea to add this to the documentation.
>

OK

> While this helps for allowing applications to transparently work with
> those non allocating futures no matter what (detoriating to a busy wait
> loop which might not what everyone expects), what I wanted to get at is
> that in order for me to consider it a real solution, it has to be adaptable
> to different executions contexts, boost::this_thread::yield,
> fiber::this_thread::yield etc...
>

adaptable at compile-time or runtime

> Please note that, while I'd prefer a generic solution to that problem
> (which currently doesn't exist), I don't think what's described is a show
> stopper, it just has to be documented appropriately.
>

using a non-allocating future seams to be a good solution to me because it
could gain in a better performance - Niall has posted some measurements of
its implementation
 on the list


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk