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