Здравствуйте, artelk, Вы писали:

A>Когда не требуется большое число одновременных задач?

Например при организации фоновых процессов не серверных приложений.

A>Без поддержки языка работать с продолжениями неудобно — будет лапша.

Что подразумевается под поддержкой языком? К пример в boost.thread продолжения давно есть и вполне себе нормально работают...

A>Интересует не "полностью аналогичная реализация", а аналогичная возможность — чтоб лапши небыло, но с масштабируемостью из коробки.

Ээээ, какая ещё масштабируемость в данном разделе? С этим обращаться ко второй части того моего сообщения... )

A>А чем с акторами проще?

Ну это собственно дело вкуса. Т.е. лично мне больше нравится такая архитектура, исключительно по эстетическим признакам. И естественно подобное нельзя пытаться кому-то навязывать. Однако могу просто показать упрощённый пример, демонстрирующий разницу в этих стилях. Весь код на C++.

Значит с сопрограммами мы можем написать так:

void OnClick() async_code
(
    textbox+=await_async([]{return download("http://...");});//download - блокирующая функция, запускается в отдельном потоке
)

А в стиле акторов будет что-то вроде:

void OnClick()
{
    thread([]{PostData(download("http://..."));}).detach();
}
void OnData(string data)
{
    textbox+=data;
}

Оно конечно длиннее, но лично мне больше нравится по ряду причин.

_>>2. Когда требуется небольшое число одновременных задач.
A>Когда требуется большое число одновременных задач?

В основном при реализации высоконагруженных серверов.

A>Еще раз, меня в этой ветке интересует, чтоб масштабируемость по ядрам была и чтоб при этом код в лапшу не превращался. И да, я имею ввиду сервис, не UI.

Если критична производительность, то я пожалуй не стал бы увлекаться всяческими архитектурными изяществами (типа сопрограмм, причём как в сомнительной .net реализации, так и даже C++ реализации), а решил бы проблему в лоб стандартными средствами. Причём в C/C++ их выбор тоже не маленький с разным уровнем продуманности программного интерфейса. Если в C++ стиле, то это Boost.Asio, а если в C стиле, то это libevent, libev, libuv. Все они достаточно вылизанные и заточенные на производительность.

_>>а для просто реализации зелёных потоков поверх пула системных ничего дописывать и не надо — оно просто работает
A>Покажи?

Так я же говорю, если без семафора, то Евгений уже показал что всё работает. Ну т.е. он не показал собственно организацию пула потоков (это отдельное реализуется или берётся готовое из того же boost'a), а продемонстрировал, что boost.coroutine вполне дружат с многопоточностью. Кстати, что самое интересное, boost.asio дружит с многопоточностью по точно такой же модели (http://www.boost.org/doc/libs/1_56_0/doc/html/boost_asio/overview/core/threads.html), так что все 3 компоненты (пул потоков, сопрограммы, асинхронный ввод/вывод) без всяких напрягов собираются в единую системку.

Но опять же надо понимать, что даже такая крайне эффективная реализации сопрограмм всё равно имеет определённые накладные расходы. Так что если уж производительность уж совсем критична, то лучше забыть про сопрограммы. И кстати не такой уж и страшный код без них выходит. )))

A>Имхо, акторы хороши, когда модель приложения в виде асинхронно общающихся объектов, посылающих друг другу сообщения, является естественной для решаемой задачи. Неясно, нафиг они нужны для вышеупомянутого сервиса и для UI с кнопкой, по которой что-то асинхронно выкачивается. Можешь объяснить?

Для сервиса я их и не предлагаю. Хотя скажем Theron может и не плохо справился бы (http://www.theron-library.com/index.php?t=page&p=performance) в смысле производительности, но не вижу особого смысла тащить его для таких целей.

А вот скажем на асинхронное скачивание по кнопке в UI акторы очень даже не плохо ложатся. Правда для такой задачи не нужна мощная библиотека типа Theron, а достаточно тривиальной реализации (см. пример выше).