Hartmut Kaiser
Giovanni Piero Deretta
: 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.
I can't parse that. Certainly I wouldn't expect boost::fiber::fiber to be a callable; then again, neither is std::thread.
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()
oh, sure, I'm completely in favor of that; but I also think that there should be a notion of an optional preferred fiber executor[1] (or scheduler), which will be used in preference to the thread local executor for plain yields and wakeup (for example a fiber::condition_variable::signal need to know where to schedule the woken up fibers, and the thread local executor might not be the correct place). [1] currently in Boost.Fiber this exists, and it is not optional. -- gpd