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

Subject: Re: [boost] [fiber] on schedulers and wakeups
From: Giovanni Deretta (gpderetta_at_[hidden])
Date: 2015-09-09 08:50:57

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. 

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

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

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.

-- gpd