On Thu, Dec 13, 2018 at 10:22 PM Gavin Lambert via Boost-users <boost-users@lists.boost.org> 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