Re: [boost] [fiber] on schedulers and wakeups

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2015-09-11 09:38:47

2015-09-11 15:14 GMT+02:00 Giovanni Deretta <gpderetta_at_[hidden]>:

>
> 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