Re: [Boost-users] Understanding fibers

Subject: Re: [Boost-users] Understanding fibers
From: Stephan Menzel (stephan.menzel_at_[hidden])
Date: 2018-12-14 07:33:13

On Thu, Dec 13, 2018 at 10:22 PM Gavin Lambert via Boost-users <
boost-users_at_[hidden]> wrote:

>
> 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.
>
>
Thank you for your response. That cleared things up big time. I think I
have a better understanding now.

Luckily I do have control over pretty much all the blocking code as I can
see now. It is business logic using an asio based client library for redis
I'm working on ( https://github.com/MrMoose/mredis ). This lib uses an
io_service with one thread and implicit strand to do all it's work. As long
as the client object exists, this thread runs. The interface to it
basically puts promises into the connections that run in the io_service and
continually do the work and set the values upon the promises. Users will
issue commands, get a future in return and wait for it but they can also
hand in callbacks.
Not such an easy thing to transform that into fiber as I am only starting
with those but I suppose absolutely possible. Just to clarify, if you allow
that one followup question:

If I simply add fiber futures to the interface, can I set the value to the
fiber promise in that other thread running the io_service, leaving the
basic architecture? This would allow me to still use the library with
regular threading and in non-fiber scenarios, which I would very much like
to. Alternatively, I could just hand in a callback with a fiber promise but
this also means that the callback is executed in the thread that runs the
client object. Hence my question.

But I do realize that is a tricky question to ask without knowledge of the
library. You already helped a lot.

Thank you very much!

Stephan