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

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2015-09-09 10:14:56

> Hartmut Kaiser <hartmut.kaiser <at> gmail.com> writes:
> > Giovanni Piero Deretta <gpderetta <at> gmail.com>:
> > > Oliver Kowalke <oliver.kowalke <at> gmail.com> writes:
> > > >
> > > > of course if this decision is given up, the user creates (on stack
> or
> > > heap)
> > > > a scheduler
> > > > and if a new fiber is created the code must specify to which
> scheduler
> > > the
> > > > fiber belongs to.
> > > >
> > > > my_scheduler ms;
> > > >
> > > > fiber f( ms, fn, arg1, arg2),
> > >
> > > Specifying an explicit scheduler would be a nice addition, but if not
> > > specified, it should default to the current scheduler for the thread.
> >
> > Hmmm, I would prefer if the scheduler and fiber interfaces were left
> orthogonal. A fiber is just a callable,
> 
> A fiber itself is not just a callable though, it is logically a sequence
> of
> callables (each callable is the next continuation at wait and yield
> points).
> At each reschedule point, the fiber needs to know which executor need to
> use
> for the next continuation.

If a fiber is not a callable, then exposing it using a
std::thread-compatible interface does not really makes sense.

> The same issue happen with plain 'executed' function object that need to
> execute another continuation, it either needs to know the executor
> explicitly or there must be a default (possibly thread specific one).

I don't see a reason not to expose the executor used to schedule the fiber.
Something like

auto exec = this_fiber::get_executor()

> There are obviously advantages to using n4406 executor interface as a
> scheduler, especially as something like that is likely to be standardized.

N4406 is not a done deal. I expect it will be a compromise between N4406 and
N4414. However I like N4406 much better as it gives a nice abstract
interface (and as we have implemented it ;-). All of HPX's higher level
parallelization constructs are implemented on top of this).

> On the other hand a specialized fiber scheduler has its advantages, for
> example it never not need memory allocation to schedule a continuation as
> it
> can always use intrusive hooks to concatenate context objects which are
> guaranteed to persist; also knowing that the task you are yielding to is a
> fiber has some advantages as you can directly swap-context to it.
> 
> It should always be possible to adapt an n4406-like executor to work as a
> fiber scheduler. Boost.Fiber might provide a generic adapter.

Nod, all it needs is a specialization of the executor_traits<>.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu