[Fibers] asio handler not respecting scheduler
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
2014/1/16 Eugene Yakubovich <eyakubovich@gmail.com>
Why does it call spawn?
spawn() resumes the fiber
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?
the scheduler does round-robin, priority is not used
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?
if a fiber is constructed it should start immediately
As an unrelated issue, I think this maybe a bug -- it's setting the active fiber to ready instead of waiting:
yield() does suspend the current fiber and puts it at the end of the ready-queue, so the state of this fiber must be READY
On Thu, Jan 16, 2014 at 2:56 PM, Oliver Kowalke <oliver.kowalke@gmail.com> wrote:
2014/1/16 Eugene Yakubovich <eyakubovich@gmail.com>
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?
the scheduler does round-robin, priority is not used
The default scheduler is round-robin but isn't it the point that it can be replaced with something else that can use priority? What's the point of having a replaceable scheduler if other parts of the code resume the fibers themselves?
yield() does suspend the current fiber and puts it at the end of the ready-queue, so the state of this fiber must be READY
Makes perfect sense. I was not thinking.
On Thu, Jan 16, 2014 at 3:38 PM, Eugene Yakubovich <eyakubovich@gmail.com> wrote:
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.
Not a bug, I believe. Oliver has clarified in previous mail that when you yield(), the calling fiber isn't waiting *for* anything: it's merely giving the scheduler a chance to run something else. The calling fiber is still ready to run, and can be resumed as soon as the scheduler picks it.
2014/1/16 Nat Goodspeed <nat@lindenlab.com>
Not a bug, I believe. Oliver has clarified in previous mail that when you yield(), the calling fiber isn't waiting *for* anything: it's merely giving the scheduler a chance to run something else. The calling fiber is still ready to run, and can be resumed as soon as the scheduler picks it.
correct - it's a better explanation
participants (3)
-
Eugene Yakubovich -
Nat Goodspeed -
Oliver Kowalke