Subject: [boost] [Fibers] asio handler not respecting scheduler
From: Eugene Yakubovich (eyakubovich_at_[hidden])
Date: 2014-01-16 15:38:52
While working on factoring out the scheduling algorithm, I noticed
that when fibers are used with asio, the completion handler manually
invokes the fiber:
void operator()( T t)
* ec_ = boost::system::error_code();
* value_ = t;
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:
// set active fiber to state_waiting
Same issue in round_robin_ws and asio/round_robin.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk