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 ( 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.
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. See: * https://www.boost.org/doc/libs/1_69_0/doc/html/boost_asio/overview/core/spaw... * https://www.boost.org/doc/libs/1_69_0/doc/html/boost_asio/overview/cpp2011/f...