Hartmut Kaiser
Giovanni Piero Deretta
: Oliver Kowalke
writes: of course if this decision is given up, the user creates (on stack or
a scheduler and if a new fiber is created the code must specify to which scheduler
heap) 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