2015-09-04 22:33 GMT+02:00 Thomas Heller
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