Boost logo

Boost Users :

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

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at