Re: [boost] Boost.Fiber review January 6-15

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
> 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