|  | Home | Libraries | People | FAQ | More | 
        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.