Boost logo

Boost Users :

Subject: Re: [Boost-users] Understanding fibers
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-12-16 22:41:58

On 14/12/2018 20:33, Stephan Menzel wrote:
> 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 ( ). 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.

If you're already using Boost.Asio, then you can just use that, without
mixing in Boost.Fiber.

Asio already supports coroutines and a std::future interface -- although
note that these are thread-blocking futures and are intended only for
use for callers *outside* the main I/O thread(s).

Inherently though an Asio io_context running on a single thread *is* a
kind of fiber scheduler for operations posted through that context,
including both actual async_* operations and arbitrary posted and
spawned work.


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