On Wed, Jun 26, 2013 at 5:35 AM, Oliver Kowalke
2013/6/26 Bjorn Reese
On 06/26/2013 08:48 AM, Oliver Kowalke wrote:
Instead of boost.context I would suggest using boost.fiber
Could you provide some guidance about the pros and cons of Context versus Fiber versus Coroutine so that we are in a better position to select the appropriate module?
boost.context - low-level library, provides mechanism to switch between execution context (assembler etc.) boost.coroutine - uses boost.context, resume-and-suspend explicitly execution of coroutine-fn, for example docu show how to use a coroutine to suspend reading from a std::stream (special character was not received -> usually stream blocks) boost.fiber - uses boost.context, provides a framework like boost.thread, fibers not explicitly resumed/suspended (done by mutext/condition/barrier ...), all fibers run concurrent in the same thread
I should have suggested Coroutine instead of Context. Boost.Context is a lower-level API on which to build high-level APIs such as Coroutine and Fiber. It exists as a separate library in case your high-level API needs are not met by either Coroutine or Fiber. Apologies. To my mind, there are two key distinctions between Coroutine and Fiber. As Oliver says, a coroutine is called, yields some value to its caller, and is called again with another set of parameter values. To its caller it resembles an ordinary function call. But within the coroutine, the yield operation itself behaves like a function call: you yield a value and then, on being called again, resume execution from the same point in your coroutine. This can involve arbitrary recursion; a coroutine is a straightforward way to implement, say, iterators over a tree structure. A fiber more closely resembles a thread. It runs independently of the code that launches it; communication between fibers is arranged using mechanisms that resemble inter-thread communications. It's just that context switching between fibers is massively cheaper than context switching between threads -- and two fibers *cannot* race to access the same data. While one fiber is running, you know that other fibers in the same thread are not. Therefore data shared between fibers are always in a known state. The other key distinction is that Coroutine is already an official Boost library. Fiber is "coming soon."