
On 14/12/2018 03:19, Stephan Menzel wrote:
So I started looking into fibers but I'm having a hard time understanding them, which is why I post here. From what I gather, what I have here is a prime use case as it matches many things the docs talk about. And yet they also suggest that the fibers are very intrusive and everything underneath do_blocking_stuff() would have to be aware of being in a fiber and yield() when appropriate. Is this correct? What would this mean?
That's correct -- fibers are intrusive and if you have blocking code that you do not control, then fibers are not an appropriate solution for you. Fibers are conceptually similar to coroutines -- the main difference is that for coroutines you explicitly choose which one you want to yield to, whereas with fibers you yield to a "fiber scheduler" (which is essentially just another coroutine that manages a list of coroutines and timers) and let it choose which one to schedule based on ready queues etc -- similar to OS threads, but all cooperatively multitasked within a single OS thread. But this means that you can't do anything to block the OS thread, otherwise you're still blocking everything from making progress.
Now, considering I would use fibers in the server, would I have to use 'fiber futures' here to make this work? To make the blocking functions automatically 'fiber aware' and yield() when they would block? This would imply replacing the thread::futures?
Yes. As long as you replace *all* thread blocking with fiber blocking, then that can work.
And if so, how will I know when the value is there and they are ready to continue? And how will I cause this continuation? Do I have to keep track of them and somehow poll() them in a loop or something?
No, the fiber scheduler does that. As is normal for futures, when whatever holds the promise publishes the result to the promise, the future can "wake up" and return that value. It won't happen immediately (because there's only one OS thread), but it can happen after the task that posted to the promise itself finishes or yields.