...one of the most highly
regarded and expertly designed C++ library projects in the
world.
— Herb Sutter and Andrei
Alexandrescu, C++
Coding Standards
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.