Re: [Boost-users] Understanding fibers

Subject: Re: [Boost-users] Understanding fibers
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-12-13 21:22:23

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.