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.
I didn't make myself clear, sorry. What I meant is that a fiber 'represents a callable', not 'is a callable'. So does 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.
We're in agreement here. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu