402a4353f7
Some reviewers disliked that to build a custom sched_algorithm subclass, you must necessarily manipulate pointers to classes in the boost::fibers::detail namespace. Redefine all such methods to use fiber_base* rather than detail::worker_fiber*. Hoist fiber_base* into boost::fibers namespace. We considered an opaque typedef rather than fiber_base*, but in fact a sched_algorithm subclass may need is_ready(). Moreover, a sched_algorithm subclass may well want to use an intrusive linked list to queue fibers. Hoist worker_fiber::nxt_ pointer into fiber_base, and remove worker_fiber::next() and next_reset() methods. This allows recasting detail::fifo in terms of fiber_base*, therefore round_robin can be stated almost entirely in terms of fiber_base* rather than worker_fiber*. Recast fiber constructor taking worker_fiber* to take fiber_base* instead. This constructor is used solely for fiber migration; with relevant functions now returning fiber_base*, we think we no longer need fiber(worker_fiber*).
boost.fiber
boost.fiber provides a framework for micro-/userland-threads (fibers) scheduled cooperativly. The API contains classes and functions to manage and synchronize fibers similiar to boost.thread.
A fiber is able to store 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 (threads are preemptively scheduled) - the running fiber decides explicitly when its yields to allow another fiber to run (context switching).
A context switch between threads costs usally thousends of CPU cycles on x86 compared to a fiber switch with less than 100 cycles. A fiber can only run on a single thread at any point in time.
Building: Detailed instructions can be found at https://svn.boost.org/trac/boost/wiki/TryModBoost.