On 09/04/2015 10:52 PM, Nat Goodspeed wrote:
On Fri, Sep 4, 2015 at 4:33 PM, Thomas Heller
wrote: On 09/04/2015 10:03 PM, Oliver Kowalke wrote:
it is safe 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.
If I may attempt to clarify your feedback:
I think you're suggesting that the documentation doesn't yet make clear that this_fiber operations, such as yield(), are valid from main() and from each new thread function, as well as from explicitly-launched fibers. Good point.
I'm not sure I understand what you mean by a non-fiber context. In effect, main() is running on the default fiber for the application's main thread. Similarly, at entry to a thread function, code is running on the default fiber for that thread. If you call this_fiber::yield() without yet having launched any other fibers, it's effectively a no-op: control detours through the fiber manager and the scheduler, which concludes that there's only one ready fiber, so the yield() call returns at once. But such a call is indeed meaningful once you launch other fibers.
Ahh, that makes sense and is a nice behavior. I wasn't aware of that. What I meant with "fiber execution context" is indeed something that is implemented in boost::fiber::fiber_manager::active_fiber_. However, my assumption was that this tss variable is only valid in task created with boost.fiber (That's what I'm used to). I think at one place or another.
If the documentation were to clarify that yield (et al.) are valid from main() (et al.), would that address your concern, or would you also want to see something like the more verbose paragraph above?
I think the reference documentation would be fine with just a small sentence from where they are valid from. That verbose paragraph is probably useful in some form of exmaple/tutorial. This information is extremely valuable if you want to await busy-wait loops, for example to implement some exponantial backof scheme as the one necessary in the non-allocating futures.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost