The idea behind using fiber inside a threadpool is, that each worker-thread executes multiple fibers - fiber would yield its execution if future::get() would block (because future is not ready)
Exactly. That's what my prototype does too. My point is that you can do this without fibers too, but you might run out of stack.
Interessting - I'd like to see how the code works. Is it possible to access your prototype?
One thing you can do with fibers that you can't easily do with a single stack is switch back to the parent task when the nested task blocks. Doing so allows you to run *other* tasks from the pool if a thread blocks and the task it is waiting for is already running elsewhere. You can also migrate tasks between threads.
That's the way boost.threadpool uses boost.fiber (but fibers are not exchanged between worker-threads -> work-stealing is done only on un-fibered tasks waiting in the local queue of a worker-thread).
IMHO, work stealing is independent from moving tasks between threads. Work stealing is a specific way of scheduling, while moving tasks between threads is a matter of resource allocation. For instance we have a simple one queue round robin fiber scheduler with several threads picking up the next available task. It's built on top of a lock-free queue and doesn't involve any explicit locking at all. If yielded for some reason tasks get re-scheduled (reinserted into the queue). That's very fast and powerful, and I don't know if it's easy to implement without fibers. Regards Hartmut