More challenging is when the application’s main loop is embedded in some other library or framework. Such an application will typically, after performing all necessary setup, pass control to some form of run() function from which control does not return until application shutdown.

A Boost.Asio program might call io_service::run() in this way.

In general, the trick is to arrange to pass control to this_fiber::yield() frequently. You could use an Asio timer for that purpose. You could instantiate the timer, arranging to call a handler function when the timer expires. The handler function could call yield(), then reset the timer and arrange to wake up again on its next expiration.

Since, in this thought experiment, we always pass control to the fiber manager via yield(), the calling fiber is never blocked. Therefore there is always at least one ready fiber. Therefore the fiber manager never calls algorithm::suspend_until().

Using io_service::post() instead of setting a timer for some nonzero interval would be unfriendly to other threads. When all I/O is pending and all fibers are blocked, the io_service and the fiber manager would simply spin the CPU, passing control back and forth to each other. Using a timer allows tuning the responsiveness of this thread relative to others.