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

4 Sep 2015

      On 09/04/2015 10:03 PM, Oliver Kowalke wrote:
...
2015-09-04 22:13 GMT+02:00 Thomas Heller :
...
On 09/04/2015 09:51 PM, Oliver Kowalke wrote:
...
2015-09-04 21:39 GMT+02:00 Thomas Heller :
The problematic portion in std::mutex/boost::mutex is exactly the missing
...
mechanism how to yield in the correct way. Even if you implement a
mechanism like in the blog post you mentioned, the problem hasn't been
solved.
why would be boost::this_fiber::yield() inappropriate?
It's inappropriate for anything not running in a boost fiber execution
context.
it is save to call boost::this_fiber::yield() from main(), e.g. each thread
has a main-context/main-fiber
Ok makes sense. So on a non-fiber context this is essentially a noop? 
Might be a good idea to add this to the documentation.

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...

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.
...
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost