Рассмотрим классическую программу, основанную на событиях, организованную вокруг основного цикла, который отслеживает и отправляет входящие события ввода-вывода. Вы вводите Boost.Fiber, потому что некоторые асинхронные последовательности ввода/вывода логически последовательны, и для тех, кто хочет писать и поддерживать код, который выглядит и действует последовательно.
Вы запускаете волокна на основной поток приложения’s, потому что некоторые из их действий будут влиять на его пользовательский интерфейс, а UI-фреймворк приложения’ разрешает операции UI только на основном потоке. Или, возможно, эти волокна нуждаются в доступе к основным данным, и было бы слишком дорого во время выполнения (или времени разработки), чтобы надежно защитить каждый такой элемент данных с помощью примитивов синхронизации потоков.
Вы должны убедиться, что основной цикл приложения’ itself не’t монополизирует процессор: что запущенные им волокна получат нужные им циклы процессора.
Решение такое же, как и для любого волокна, которое может претендовать на процессор в течение длительного времени: введите вызовы this_fiber::yield()
. Наиболее простой подход заключается в вызове yield()
на каждой итерации существующего основного цикла. По сути, это унифицирует основной цикл приложения’ с Boost.Fiber’s внутренний основной цикл. yield()
позволяет диспетчеру волокон запускать любые волокна, которые стали готовыми с момента предыдущей итерации основного цикла приложения’s. Когда эти волокна имеют поворот, управление переходит к основному волокну резьбы’, которое возвращается из выхода()
и возобновляет основной цикл приложения’.