fa9cf0d0d2
There's a blanket statement under 'Exceptions' that any exception not caught
by a running fiber will cause the program to terminate. fiber_interrupted is
an exception to this rule: that exception will terminate the fiber, but not
the whole program.
Explain that when a fiber running packaged_task is terminated by
fiber_interrupted, and another fiber calls future::get() on the future from
that packaged_task, fiber_interrupted will be rethrown regardless of
disable_interruption. This is implicit in existing material, but worth making
explicit.
Explicitly state that a thread's main fiber may call (e.g.) this_fiber::yield().
[un]bounded_channel::try_{push,pop}() are not interruption_points. Remove them
from the big list.
Semantics of operator<(fiber, fiber) depend solely on operator<(fiber::id,
fiber::id). Restating semantics of the latter function not needed.
Add a note clarifying the phrase "timeout-related exceptions."
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.
boost.fiber is C++14-only!