Subject: Re: [boost] Boost.Fiber review January 6-15
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2014-01-08 09:02:42
> 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
> 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
In fact, in my book a fiber _is_ a thread-like construct and having it
expose a new interface is just confusing and unnecessary.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk