While working on factoring out the scheduling algorithm, I noticed that when fibers are used with asio, the completion handler manually invokes the fiber: boost-fiber/include/boost/fiber/asio/detail/yield.hpp: In yield_handler<T>: void operator()( T t) { * ec_ = boost::system::error_code(); * value_ = t; fiber_->set_ready(); boost::fibers::detail::scheduler::instance()->spawn( fiber_); boost::fibers::detail::scheduler::instance()->run(); } Why does it call spawn? Shouldn't the scheduler (run method that follows) decide which fiber to run next? What happens if there's another fiber with a higher priority that's ready? A similar issue also comes up when launching a new fiber. The documentation supports the implementation in that the control immediately is transferred to the new fiber. However, shouldn't the scheduling algorithm decide when the new fiber should run? As an unrelated issue, I think this maybe a bug -- it's setting the active fiber to ready instead of waiting: void round_robin::yield() { <snip> // set active fiber to state_waiting active_fiber_->set_ready(); <snip> } Same issue in round_robin_ws and asio/round_robin. Regards, Eugene