The review of Boost.Fiber by Oliver Kowalke begins today, Monday January 6th, and closes Wednesday January 15th.
-----------------------------------------------------
About the library:
Boost.Fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperatively. The API contains classes and functions to manage and synchronize fibers similar to Boost.Thread. Each fiber has its own stack.
A fiber can save the current execution state, including all registers and CPU flags, the instruction pointer, and the stack pointer and later restore this state. The idea is to have multiple execution paths running on a single thread using a sort of cooperative scheduling (versus threads, which are preemptively scheduled). The running fiber decides explicitly when it should yield to allow another fiber to run (context switching). Boost.Fiber internally uses coroutines from Boost.Coroutine; the classes in this library manage, schedule and, when needed, synchronize those coroutines. A context switch between threads usually costs thousands of CPU cycles on x86, compared to a fiber switch with a few hundred cycles. A fiber can only run on a single thread at any point in time.
docs: http://olk.github.io/libs/fiber/doc/html/ git: https://github.com/olk/boost-fiber src: http://ok73.ok.funpic.de/boost.fiber.zip
The documentation has been moved to another site; see the link above. If you have already downloaded the source, please refresh it; Oliver has added some new material.
One of the main questions arising for me when looking through the code is why doesn't the fiber class expose the same API as std::thread (or boost::thread for that matter)? This would make using fibers so much more usable, even more as the rest of the library was aligned with the C++11 standard library. In fact, in my book a fiber _is_ a thread-like construct and having it expose a new interface is just confusing and unnecessary. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu