2015-09-11 15:14 GMT+02:00 Giovanni Deretta
As I said elsewhere, there is no fundamental reason and, although I consider the idle fiber a better solution, I would be perfectly fine with a scheduler that doesn't have such a thing and simply called the idle function when appropriate.
I try to figure out what would be the benefits/disadvantages Note that unconditionally calling idle at the end of yield is not
necessarily ideal though, as the idea is that it might execute more expensive operations that you want to do only at the end of an 'epoch' (i.e. when all ready fibers have executed once). Adding a conditional test on yield opens up the possibility of a misprediction. At that point the cost of an additional fiber switch is minimal.
agreed - a terminated fiber would earlier release its resources
The fact is, often there is an existing idle fiber anyway; if you spawn a dedicated thread to run a scheduler, the thread has an implicit fiber which would go otherwise unused; if you are running on top of another scheduler (for example boost::asio::io_service or one of the proposed executors), the idle fiber is simply the context of the underlying scheduler callback; in this case after control reaches back the idle fiber, it is appropriate to return control to the underlying io_service and reschedule another callback (with asio::post for example);
OK - I'll take this into account for
- lack of proper cross scheduler wakeup.
- unconditional sleep when the scheduler is empty. - the handling of waiting tasks (including the clock wait queue).
your concerns are already addressed in another branch
Idle tasks, nested schedulers would all be nice to have for me, but not deal breakers.
I'll try a version with an idle fiber per scheduler