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

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2015-09-04 16:33:21

On 09/04/2015 10:03 PM, Oliver Kowalke wrote:
> 2015-09-04 22:13 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:
>
>> On 09/04/2015 09:51 PM, Oliver Kowalke wrote:
>>
>>> 2015-09-04 21:39 GMT+02:00 Thomas Heller <thom.heller_at_[hidden]>:
>>>
>>> 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
>