Кто нибудь применял сопрограммы на практике?

Я пока нашел только такие варианты реализации:

• использование API ОС (например Fiber'ы в винде)  - Boost.Coroutine (в разработке уже несколько лет, в буст не входит)
• различные варианты с устройством Даффа, в зависимости от сложности макросов препроцессора может выглядеть весьма прилично, например yield может выглядеть так:
  

  Код

  yield asio::async_write(socket, asio::buffer(working_buffer, length), *this);  // yield - макрос // сопрограмма реализована как функтор, который постоянно передается asio в async_* функции

  
  (http://blog.think-async.com/2009/08/composed-operations-coroutines-and-code.html)
• ручная реализация переключения контекстов, с выделением стека в хипе

С фиберами все выглядит просто и удобно, но у меня есть сомнения что фибер расходует меньше памяти чем нормальный поток.
Устройство Даффа плохо тем что возникают потенциальные сложности с локальными объектами в сопрограмме, макросы тяжело отлаживать.
Ручная работа со стеком крайне сложна в реализации и фактически является заменой фиберов.


Это сообщение отредактировал(а) GoldFinch - 25.3.2010, 12:26

Я правильно понимаю, сопрограмма это таже же асинхронная очередь событий как и в Qt? То есть один поток используется для обработки нескольких циклов. Предположим я вызываю сопрограмму, её вызов становится в очередь до того момента когда я выйду из итерационного цикла и не войду в него снова. Как только я покинул область видимости функции вызывается моя сопрограмма, которая блокирует вход моего предыдущего цикла пока не завершится и не вызовет меня обратно точно также по завершении. В общем yield это аналог emit в Qt с Qt::QueuedConnection.

Классический вызов сопрограммы вызывает НЕМЕДЛЕННОЕ переключение на вызванную сопрограмму. Обратное переключение так же должно производится явно таким же вызовом (но теперь в другую сторону)