Первый взгляд на SObjectizer 5 - C/C++. Прикладные вопросы

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

E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.

по поводу отсутствия трэйсов в исключениях:
давно пользую классик (исходники приводил здесь) для получения backtrace. давно ждал когда бустеры аппрувнут boost:exception... в 1.36 это наконец случилось. выкинул некоторые свои велосипеды и сделал себе следующее:

namespace example {

class exception : public std::exception, public boost::exception
{
public:
    /// Type of attached to exception backtrace data
    typedef boost::error_info<struct tag_backtrace, debug::backtrace> trace_info;
    /// Default constructor push backtrace info
    exception()
    {
        *this << trace_info(debug::backtrace());
    }
    ~exception() throw()
    {
    }
    template <typename T>
    boost::shared_ptr<const typename T::value_type> get() const
    {
        return boost::get_error_info<T>(*this);
    }
    boost::shared_ptr<const debug::backtrace> trace() const
    {
        return get<trace_info>();
    }
    /// default implementation for \c what()
    char const* what() const throw()
    {
        return boost::exception::diagnostic_information();
    }
};

}                                                          // namespace example

пример использования:

namespace my {

struct exception : public example::exception {};

}                                                          // namespace my

void foo()
{
    throw my::exception();
}

MY_AUTO_TEST_CASE(exception_test)
{
    try
    {
        foo();
    }
    catch (const my::exception& e)
    {
        // print backtrace to std error device
        std::cerr << *e.trace() << std::endl;
    }
}

наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...
насколько я понял по обсуждениям из ветки где опубликовал сорцы backtrace в винде тоже можно получить stack trace...

По крайней мере, это будет OpenSource проект под BSD (или ей подобной) лицензией

E>Некоторые свои мысли о том, зачем нужен SO5 и что в нем должно быть, я попытался описать здесь.

E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.

Пара вопросов по поводу подсистемы обмена сообщениями:
1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).
2. Твоя система сообщений полностью децентрализована, так ведь? Т.е. нет ни global ordering, ни persistence, ни recovery via replay (это главные проблемы TivRV)? Если так, есть какие-то мысли сделать это дело?
3. Каковы характеристики твоей подсистемы? Сколько она может сообщений в секунду прокачать по гигабитной сети, на одном хосте?
4. Насколкьо все завязано на формат сообщений? Можно ли использовать свой формат (скажем, FIX)?

Насчет исключений — посмотри на boost::exception — там есть и стеки, и цепочки

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

Z>наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...

Т.е., если приложение скомпилировано в release и без отладочной информации, то backtrace не будет?

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

J>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).

Нет.
И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?

J>2. Твоя система сообщений полностью децентрализована, так ведь?

Если речь идет о распределенных приложениях, то да -- децентрализована.

J>Т.е. нет ни global ordering, ни persistence, ни recovery via replay

Нет. Если разработчику это нужно, то ему самому придется этим заниматься.

J>Если так, есть какие-то мысли сделать это дело?

Необходимости в этом не было. Поэтому не было и мыслей. Будет необходимость -- будут и мысли и, наверное, реализация.

J>3. Каковы характеристики твоей подсистемы? Сколько она может сообщений в секунду прокачать по гигабитной сети, на одном хосте?

На одном хосте в режиме запрос-ответ (длина запроса 256 байт) ~6200 сообщений в секунду. В асинхронном режиме группами по 100 пакетов -- ~11000, группами по 1000 пакетов -- ~12000 сообщений в секунду. Это на Core2Duo 2GHz, WinXP SP2, VC++ 7.1SP1.

На Gigabit проверю завтра на работе.

J>4. Насколкьо все завязано на формат сообщений? Можно ли использовать свой формат (скажем, FIX)?

Сейчас сильно завязано. Все общение идет по SOP протоколу, который использует свою сериализацию. Можно делать свою сериализацию для собственных типов -- вот как-то так.

Хотя опять же -- инструмент свой, можно повернуть его так, как нужно.

J>Насчет исключений — посмотри на boost::exception — там есть и стеки, и цепочки

Посмотрю.

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

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

Z>>наследую классы исключений от базового и в каждом имею backtrace который при соответствующем debug/verbose level'e можно распечатать...

E>Т.е., если приложение скомпилировано в release и без отладочной информации, то backtrace не будет?

release — будет, но кривое и, возможно, с выпавшими кадрами.

без отладочной информации — а зачем? сейчас же нормальные компиляторы позволяют генерить ее в релизной версии, причем ее можно и положить где-нть рядом и не поставлять в финальном дистрибе.
без нее стек будет выглядеть примерно так:
модуль — адрес
модуль — адрес
...

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

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

J>>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).

E>Нет.
E>И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?

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

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

E>На одном хосте в режиме запрос-ответ (длина запроса 256 байт) ~6200 сообщений в секунду. В асинхронном режиме группами по 100 пакетов -- ~11000, группами по 1000 пакетов -- ~12000 сообщений в секунду. Это на Core2Duo 2GHz, WinXP SP2, VC++ 7.1SP1.

E>На Gigabit проверю завтра на работе.

На двух хостах (сервер Core2Duo 2.4GHz, WinXP SP3; клиент Core2Duo 2GHz, WinXP SP2):
— синхронный режим запрос-ответ: ~1600;
— асинхронный режим, группы по 100 пакетов -- ~3500;
— асинхронный режим, группы по 1000 пакетов -- ~13500;
— асинхронный режим, группы по 1100-1300 пакетов -- ~16000..17000;

2jazzer: если не сложно, дай оценку таким цифрам с точки зрения TibcoRV. А то мне пока таких скоростей хватает, но я не знаю, к чему еще можно стремиться.

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

J>>>1. Есть ли возможность прикрутить свой собственный движок? Например, ту же упомянутую TibRV (в конце концов, она отлично реализует роутинг и диспетчеризацию).

E>>Нет.
E>>И не понятно -- зачем? Если уже есть движок для диспетчеризации сообщений, то зачем нужен SO?

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

Ну как раз такая постановка вопроса и не очень для меня понятна. Если механизмы диспетчеризации из TibcoRV устраивают, но хочется большего, то можно же создать свою предметно-ориентированную нашлепку над TibcoRV.

А если механизмы диспетчеризации из TibcoRV не устраивают...

В любом случае SO может использоваться только в небольшой части приложения, поскольку SO не налагает сколько-нибудь серьезных требований. Так что в одной части может использоваться TibcoRV, а в другой -- SO.

Ключевой чертой SO является использование диспетчера для предоставления контекста для запуска событий агентов. В SO определяется интерфейс диспетчера, который может быть реализован по разному. Так, в SO есть диспетчер главной нити для Qt -- в нем события агентов, завязанных на этот диспетчер, передаются на главную нить приложения средствами Qt и запускаются на ней же.

Может быть, можно будет реализовать этот интерфейс и для средств диспетчеризации TibcoRV. Только здесь нужно понимать, что придется использовать понятия SO (такие как agent_t, msg_data_t, dispatcher_binding_t, event_data_t). И я не уверен, что они гладко лягут на TibcoRV.

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

E>Доброго дня!

E>Недавно вышедшая версия 4.4.0-b6 стала достаточно близким приближением к тому, что мне хотелось бы видеть в финальном релизе 4.4.0. А посему появляется время задуматься о том, что будет дальше...
Из люопытства заглянул на http://sobjectizer.sourceforge.net/. Создалось противоречивое впечатление о проекте. С одной стороны
документация есть, на первый взгляд, добротная — http://sobjectizer.sourceforge.net/docs/so4.4/index.html (зтолько ачем она на русском — не очень понятно), релизы регулярно выходят. С другой стороны судя по статистике загрузок (http://sourceforge.net/project/stats/detail.php?group_id=162441&ugn=sobjectizer&type=prdownload&mode=alltime&package_id=0) выходит что лучшие времена проекта были года полтора назад. Сейчас заглохло как-то все.
Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?

Алексей

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

E>>Недавно вышедшая версия 4.4.0-b6 стала достаточно близким приближением к тому, что мне хотелось бы видеть в финальном релизе 4.4.0. А посему появляется время задуматься о том, что будет дальше...
A>Из люопытства заглянул на http://sobjectizer.sourceforge.net/. Создалось противоречивое впечатление о проекте. С одной стороны документация есть, на первый взгляд, добротная — http://sobjectizer.sourceforge.net/docs/so4.4/index.html (зтолько ачем она на русском — не очень понятно), релизы регулярно выходят.

На русском потому, что мой уровень владения английским языком не позволяет писать ее на английском. Уж лучше пусть будет нормальная документация на русском, чем плохая на английском, имхо. Перевести то ее, при желании и необходимости можно будет, а вот улучшить плохую документацию -- вряд ли

A>Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?

Мне не известно о том, чтобы SObjectizer кем-то использовался в серьезных проектах. Время от времени люди пишут о том, что попробовали и чего-то им не хватило или столкнулись с какой-то проблемой. Но продолжили ли они эксперименты с SObjectizer -- я не знаю.

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

A>Вопрос: проектом кто-нибудь пользуется, кроме разаботчиков?

Например, в настоящее время SObjectizer используется в системе тестирования технологических алгоритмов ПО процессорно-релейной централизации, разработанной в лаборатории "БЭМС ТС" БелГУТа.
SObjectizer был выбран как удобный инструмент диспетчеризации для эмуляции полевых устройств и поведения дежурного по станции за АРМ'ом. На тот момент разработчики системы уже использовали C++ как основной и в рамках проекта нужно было решить вопрос с точной генерацией событий и поведением полевых устройств. Агентная модель и инструментарий SObjectizer пришлись как раз кстати.

К слову говоря, выбор был не совсем случайным. Я являюсь разработчиком в Intervale и опыт использования SObjectizer был. С одной стороны было предложено использование именно SObjectizer, с другой стороны было сразу ясно какие преимущества дает такое решение.

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

E>Приглашаю к обсуждению всех, кто интересуется событийно-ориентированным и/или агентно-ориентированным программированием вообще и SObjectizer-ом в частности. А так же тех, кто пытался, пытается или только еще хочет попытаться создать собственный событийно-ориентированный фреймворк. Хотя бы в порядке обмена опытом.

Скажи, решена ли проблема контроля загрузки, и как?

E>Негативным проявлением подобной непредсказуемости агентного приложения является ситуация, при которой агенты начинают генерировать друг другу больше сообщений, чем они в состоянии обработать.

Здравствуйте, Кодёнок, Вы писали:

Кё>Скажи, решена ли проблема контроля загрузки, и как?

В рамках текущей версии 4.4 разрешить ее на уровне SObjectizer пока не представляется возможным, т.к. в 4.4 вообще отсутствует такое понятие, как очередь сообщений для одного агента. Поэтому ее решение полностью отдано на откуп прикладному разработчику.

Этому аспекту планируется уделить очень серьезное внимание как раз в будущих версиях, которые пока условно называются SObjectizer5. Мы у себя провели некоторые предварительные обсуждения того, какими средствами можно защищать приложения от неконтролируемого распространения сообщений. Они как раз были описаны в в моих заметках:

* введение ограничений на размеры очередей заявок для отдельных агентов. Лишние заявки просто игнорируются и выбрасываются. Может быть при этом агент сам может указать какие заявки могут выбрасываться;
* выбрасывание повторных сообщений. Например, агент раз в секунду получает периодическое сообщение msg_check_activity. Если из-за загрузки системы он не успел получить предыдущее msg_check_activity (заявка все еще находится в очереди заявок), то новое msg_check_activity игнорируется;
* перенаправление сообщений на других агентов, которые, к примеру, вместо прикладной обработки сообщения сразу отсылают отрицательный ответ отправителю сообщения.

В любом случае, когда такие меры предпринимает сам SObjectizer, это означает, что часть прикладных сообщений будет либо выброшена, либо обработана не так, как это хотел бы пользователь. Следовательно, прикладная программа должна быть создана в расчете на такое поведение. Что, в итоге означает, что само приложение должно предпринимать меры по защите от собственной перегрузки.

Сам я считаю, что контроль загруженности является задачей прикладного программиста. SObjectizer сам по себе не генерирует лишней работы, это прикладная программа эту работу провоцирует. Причем, иногда, совершенно на ровном месте.

Вот совсем недавний пример. Написанный на SObjectizer компонент должен был опрашивать некое устройство раз в пять секунд. Программист для этого завел периодическое таймерное сообщение с темпом пять секунд. По его пришествии производился опрос устройство. Операции опроса так же давался тайм-аут на пять секунд, т.к. предполагалось, что уж за это время ответ от устройства должен быть получен. И так оно и было, пока устройство не начало сбоить. И операция опроса завершалась по истечении пятисекундного тайм-аута.

И произошла классическая ситуация -- таймерные заявки генеряться быстрее, чем они обрабатываются, поскольку операция опроса устройства чуть-чуть длительнее периода генерации заявок.

Причем темп в пять секунд -- это просто огромные цифры по сравнению с другими задачами, на которых используется SObjectizer. И все равно здесь мы умудрились напортачить. А если бы SObjectizer, например, просто выбрасывал "лишние" таймерные заявки, то это бы только замаскировало ошибку разработчика.

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

E>Сам я считаю, что контроль загруженности является задачей прикладного программиста. SObjectizer сам по себе не генерирует лишней работы, это прикладная программа эту работу провоцирует. Причем, иногда, совершенно на ровном месте.

Спасибо. Но я не совсем согласен, что это должна быть исключительно задача программиста.

Если сравнивать процессы ОС и актеров (которые сами по себе есть легковесные процессы), то я вижу три вида перегрузки, на которые реакция твоей системы и современной ОС существенно разная:

1. Переполнение стека.
Процессы системы: функция вызывает сама себя два раза подряд (если нет раскрутки хвостовой рекурсии — то одного хватит). Система защищает другие процессы прибиванием процесса, где произошло переполнение стека (если он не обработает исключение).
Актеры: обработчик сообщения шлет сам себе два таких же сообщения. Произойдет зажирание памяти под 100%, другие актеры и вся система — парализованы.

2. Загрузка процессора.
Процессы системы: бесконечный цикл или тяжелые вычисления. Система защищает другие процессы, распределяя время по приоритетам. Другие процессы не будут парализованы.
Актеры: обработчик сообщения делает тяжелое вычисление и шлет сам себе такое же сообщение. Или создает миллион помощников, каждый из которых получает сообщение. Если все актеры равны, то остальные актеры, которых может быть мало — всего 10 000 например, будут парализованы этим миллионом.

3. Зажирание памяти.
Это бесконечное создание новых объектов или актеров. От этого никто не защищает, хотя некоторые ОС (Linux) позволяют выборочно ограничить процессам максимум выделяемой памяти.

В случае с обычными процессами, программист только делит систему на процессы/потоки, и получает готовую приемлемую защиту в пунктах 1 и 2, а в п.3 администратор (или родительский процесс) может хотя бы ограничить вред.

Можно ли в агентно-ориентированной системе сделать такого же рода защиту, чтобы программист (в данном случае тим-лидер или архитектор) только поделил агентов-актеров на некоторые условные модули и подмодули (в смысле что каждый актер принадлежит одному конкретному модулю, хотя связи между ними могут быть произвольные), и затем даже в случае сбоя какого-то модуля, написаного новичком, остальные не были парализованы? Например, сбой в управлении вентиляцией не обязательно должен выводить из строя всю систему здания — охрану, освещение и т.д.

В какого рода контроль загрузки целится SO5, или это еще не решено? В идеале конечно хочется такое же полуавтоматическое распределение ресурсов и защиту, что дают существующие механизмы ОС.

Здравствуйте, Кодёнок, Вы писали:

Кё>Но я не совсем согласен, что это должна быть исключительно задача программиста.

Поскольку ты не одинок в этом мнении, мы и хотим заложить в SO5 средства для защиты от черезмерной загрузки

Кё>1. Переполнение стека.
Кё>2. Загрузка процессора.
Кё>3. Зажирание памяти.

Интересно. Я никогда не думал о том, что на SObjectizer можно распространить некоторые механизмы ОС. Поскольку ОС может прибивать процессы, а вот SObjectizer не может просто так уничтожать агентов.

Кё>Можно ли в агентно-ориентированной системе сделать такого же рода защиту, чтобы программист (в данном случае тим-лидер или архитектор) только поделил агентов-актеров на некоторые условные модули и подмодули (в смысле что каждый актер принадлежит одному конкретному модулю, хотя связи между ними могут быть произвольные), и затем даже в случае сбоя какого-то модуля, написаного новичком, остальные не были парализованы?

Наверное, что-то можно придумать. Надо покурить эту тему.

>Например, сбой в управлении вентиляцией не обязательно должен выводить из строя всю систему здания — охрану, освещение и т.д.

Самое надежное решение здесь -- это разбивать систему на отдельные SObjectizer-процессы. Чтобы падение одного не сказывалось на других.

Кё>В какого рода контроль загрузки целится SO5, или это еще не решено?

Еще не решено. Я перечислил три пункта, которые бы были востребованны в наших системах. Если будут еще какие-то идеи и предложения, то мы очень внимательно их рассмотрим и, при их состоятельности, обязательно попробуем реализовать.

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

Из фич я ещё считаю важным следующее.

Поддержка паттерна запрос-ответ.
Вместе с сообщением всегда идёт отправитель сообщения. Получатель сообщения может с помощью специальной функции сказать, что он отвечает на такое-то сообщение. Соотв. ответ маршрутизируется только одному агенту, не зависимо от обстоятельств.

Контекст сообщения.
Связано с паттерном запрос-ответ. Отправитель может прикрепить к сообщению произвольный контекст, по сути тоже сообщение. Получатель его не видит, но если он отвечает на это сообщение, то контекст возвращается к отправителю исходного сообщения.
Критично для поддержки stateless агентов.

Перехват сообщений.
Сторонний агент подписывается на перехват неких сообщений. Перехват может происходить (1) синхронно при отправке, (2) синхронно при получении, (3) асинхронно. При перехвате агент может прервать обработку. Может ли он менять сообщение — сложный вопрос. Главное — что перехват должен абсолютно прозрачен для исходных агентов — и отправителя и получателя.
Критично для расширяемости. Позволяет реализовывать например следующую схему. Идёт общение по какому-то каналу. Подкладываем dll'ку, агент из которой перехватывает все входящие и исходящие сообщения и прозрачно архивирует/деархивирует или шифрует/дешефрует.

Не знаю, возможно это и подразумевается под интеграцией MBAPI в SObjectizer.

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

Возможно, подобная интеграция MBAPI с ядром SObjectizer расширит SObjectizer новыми понятиями. Так, в SObjectizer существуют только агенты и рассылка сообщений (целенаправленная или широковещательная). Добавление mbox-ов и перехвата/перемаршутизации сообщений может ввести в SObjectizer такие понятия, как:

* доска объявлений -- это специальная сущность, используемая для широковещательной рассылки сообщений всем заинтересованным получателям. Сообщение как бы вывешивается на доску объявлений и все желающие могут прочитать его;
* канал, в котором все получатели сообщения выстраиваются в цепочку и сообщение передается от одного звена цепочки к другому. На уровне канала возможен перехват сообщения, его модификация и перемаршрутизация.

Почему новые понятия? Доска объявлений — это и есть широковещательная рассылка как она есть сейчас. Канал — это и есть целенаправленная рассылка, как она есть сейчас. Или я совсем чего-то не догоняю?
Другое дело, что эти существующие понятия можно расширить новыми фичами. Но по-сути вроде ничего не меняется.

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

R>Почему новые понятия? Доска объявлений — это и есть широковещательная рассылка как она есть сейчас. Канал — это и есть целенаправленная рассылка, как она есть сейчас. Или я совсем чего-то не догоняю?
R>Другое дело, что эти существующие понятия можно расширить новыми фичами. Но по-сути вроде ничего не меняется.

Канал -- это явно выстроенная цепочка агентов, модицифирующих некую информацию по мере ее продвижения по каналу. Например, первый агент формирует текст, второй агент обрамляет этот текст в формат некоего пакета данных, третий шифрует этот пакет, четвертый подписывает, пятый обрамляет результат в виде нового пакета данных, шестой передает пакет в коммуникационный канал или сохраняет в БД. По сути, это явное воплощение pipes and filters шаблона.

Я задумался о его выделении в специальное понятие, поскольку, на мой взгляд:
— для канала требуются специальные средства конструирования канала. Например, агент-шифратор должен предшествовать агенту-подписывателю. Это должно гарантироваться вне зависимости от того, какой из этих агентов первым зарегистрируется в системе;
— канал должен оказываться разорванным при выпадении значимых звеньев. Например, если агент-шифратор прекратит по какой-то причине свою работу, то сообщения должны перестать ходить по каналу. В то же время, какие-то незначимые узлы могут добавляться и удаляться из канала безболезненно. Например, между агентом-формирователем текста и агентом-упаковщиком может на какое-то время вклиниться агент, собирающий статистику или проверяющий орфографию. Изъятие такого агента из канала не должно нарушать движение данных по каналу;
— передача сообщения между элементами канала, возможно, должа иметь какую-то специальную форму. Т.е. должен быть новый метод в API, который явно указывает, что сообщение передается либо дальше по каналу, либо должно отсылаться в другой канал.

По опыту использования MBAPI можно сказать, что организация каналов возможна и просто при наличии средств перехвата и перемаршрутизации сообщений. Но здесь не получается достичь того, чтобы:
— агенты занимали нужные места в цепочке. В MBAPI это получается лишь посредством приоритетов, т.е. приоритеты нужно просчитывать заранее, а в последствии их приходится перераспределять для того, чтобы куда-то вставить новое звено;
— не обеспечивается разрыв канала, если какое-то из ключевых звеньев удаляется. Получается, что просто исчезает перехватчик с некоторым приоритетом. А остальные перехватчики продолжают свою работу.

Ну и плюс ко всему вышеизложенному, для каналов можно разрабатывать средства контроля нагруженности и инструменты для предотвращения/преодоления перегрузок.

Доска объявлений изначально задумывалась как некое понятие для коммутации каналов. Например, доска объявлений может быть как точкой входа в канал (начальной точкой), так и точкой завершения канала (целевой точкой). Тогда какой-то агент вывешивает сообщение на доску объявлений и оно автоматом проваливается во все каналы, для которых доска объявлений является начальной точкой. Аналогично, когда последнее звено канала выдает наружу сообщение, то сообщение оказывается вывешенным на целевой доске объявлений (и, возможно, провалиться в какие-то другие каналы).

Однако, пару недель назад я пытался обдумать, как вообще может выглядеть использование досок объявлений в SO-приложениях. И ничего путного не придумал. Поэтому, возможно, этого понятия не будет, т.к. оно действительно хорошо реализуется широковещательной рассылкой. Но в тексте "Первого взгляда..." (который был написан довольно давно) я решил это понятие оставить.

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

R>Поддержка паттерна запрос-ответ.
R>Вместе с сообщением всегда идёт отправитель сообщения. Получатель сообщения может с помощью специальной функции сказать, что он отвечает на такое-то сообщение. Соотв. ответ маршрутизируется только одному агенту, не зависимо от обстоятельств.

R>Контекст сообщения.
R>Связано с паттерном запрос-ответ. Отправитель может прикрепить к сообщению произвольный контекст, по сути тоже сообщение. Получатель его не видит, но если он отвечает на это сообщение, то контекст возвращается к отправителю исходного сообщения.
R>Критично для поддержки stateless агентов.

Сначала несколько общих слов.

В SObjectizer хочется придерживаться принципа С++: не платишь за то, что не используешь. Применительно к запросу-ответу и контексту сообщения это означает, что SO не должен добавлять каких-либо накладных расходов к сообщениям, которые не участвуют в реализации данных паттернов.

А это означает, что поддержку идентификаторов запросов/ответов и контекстов сообщений, имхо, лучше вынести на более высокий уровень. Например, SO никак не поддерживает этих понятий. Но есть базовые классы для сообщений, наследование от которых добавляет поддержку идентификаторов/контекстов к сообщениям. Требуется агенту получать сообщения в ответ на свои запросы -- пусть оформляет соответствующим образом запрос.

Что касается контекста, то это вообще интересный вопрос.

Во-первых, я не согласен, что контекст не должен быть виден получателю сообщения. Более того, с сообщением может быть связано несколько контекстов. Вот сейчас у нас, средствами MBAPI реализовано несколько распределенных программных систем, в которых прослеживаются цепочки компонентов. Допустим, у нас есть операция, состоящая из трех фаз -- S (начало), R (результат), F (завершение). При наличии трех компонентов в системе это выглядит так:

  A                B               C
  |--------S------>|               |
  |                |--------S----->|
  |                |<-------R------|
  |<-------R-------|               |
  |--------F------>|               |
  |                |--------F----->|

Компонент B является stateless компонентом. Он должен где-то сохранить информацию о том, от кого поступил S, куда передать R и куда отослать F. Если компонент C так же является stateless-компонентом, то ему так же нужно понимать, для какого S приходит F и что при получении F нужно делать (в зависимости от того, какой был R). Для того, чтобы это все работало, компоненты B и C добавляют в сообщения свои контексты. Получается что-то вроде:

  A                B               C
  |--------S------>|               |
  |                |-----S(b)----->|
  |                |<--R(b,c)------|
  |<--R(b',c)------|               |
  |---F(b',c)----->|               |
  |                |-----F(c)----->|

где b, b' и c -- это связанные с сообщением контексты.

Если добавить в эту схему еще один компонент, то количество контекстов, задействованных в сообщениях может еще возрасти.

Так же, контексты вместе с сообщениями могут собираться в БД. Скажем, если есть какой-то промежуточный узел, предназначенный для сглаживания пиков нагрузки и который гарантирует на своем выходе некую стабильную скорость передачи сообщений. При получении всплеска трафика он может сохранить избыточные сообщения в БД, а затем поднимать их оттуда по мере надобности.

Имхо, все это проще достигается, если контексты представлены обычными полями сообщения и видны пользователю.

Во-вторых, понятие контекста известно под термином Async Completion Token (судя по твоей оценке на этом сообщении мне не нужно лишний раз об этом рассказывать). И его поддержка, имхо должна быть не столько частью SObjectizer, сколько частью прикладной логики (что из себя представляет контекст, сколько контекстов, какие между ними связи) и системы сериализации (чтобы неизвестные промежуточным узлам структуры данных безпрепятственно проходили через узел).

R>Перехват сообщений.
R>Сторонний агент подписывается на перехват неких сообщений. Перехват может происходить (1) синхронно при отправке, (2) синхронно при получении, (3) асинхронно. При перехвате агент может прервать обработку. Может ли он менять сообщение — сложный вопрос. Главное — что перехват должен абсолютно прозрачен для исходных агентов — и отправителя и получателя.
R>Критично для расширяемости. Позволяет реализовывать например следующую схему. Идёт общение по какому-то каналу. Подкладываем dll'ку, агент из которой перехватывает все входящие и исходящие сообщения и прозрачно архивирует/деархивирует или шифрует/дешефрует.

На мой взгляд, поддержка в SO понялия канала будет решать изрядную долю задач, которые могли бы реализовываться с помощью перехвата сообщений. А нужно ли будет иметь перехват еще для чего-нибудь -- это уже отдельный вопрос.

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

Интересные вещи можно найти в грядущей библиотеке PPL от Microsoft (которая станет частью следующей версии MSVC):
Parsing a File with Agents

HRESULT LogChunkFileParser::ParseFile() {
  unbounded_buffer<AgentMessage> msgBuffer = 
    new unbounded_buffer<AgentMessage>();  
  agent_task* pParserAgent = agent_task::start([&] {
    AgentMessage msg;
    while((msg = receive(msgBuffer))->type != EXIT) {
      Parse(msg->pCurrentLine);
      delete msg->pCurrentLine;
    }
  });
  HRESULT hr = reader->OpenFile(pFileName);
  if (SUCCEEDED(hr)){
    while(!reader->EndOfFile()) {
      WCHAR* wszLine = new WCHAR[MAX_LINE];
      hr = reader->ReadLine(wszLine, MAX_LINE);
      if (SUCCEEDED(hr)) {
         send(msgBuffer, AgentMessage(wszLine));
      }
    }
    send(msgBuffer, AgentMessage(EXIT));
    hr = agent_task::wait_for_completion(pParserAgent);
  }
  return hr;
};

Полная версия тут:
http://msdn.microsoft.com/en-us/magazine/cc817396.aspx

И здесь ещё видео Parallel Computing Platform: Asynchronous Agents for Native Code
http://channel9.msdn.com/posts/Charles/Parallel-Computing-Platform-Asynchronous-Agents-for-Native-Code/
Это тоже о PPL.

Наводит на мысли. Вообще это первый прецедент промышленной Агентно-орентированной библиотеки для нативного кода (не считая SObjectizer). Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

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

R>Наводит на мысли. Вообще это первый прецедент промышленной Агентно-орентированной библиотеки для нативного кода (не считая SObjectizer).

Ну что тут сказать... Радует, что выбранное нами когда-то направление сейчас доказывает свою состоятельность в виде этой разработки MS. С другой стороны, агентному подходу уже сто лет в обед и, вероятно, первая серьезная система для агентного программирования -- это язык Scheme (см. http://en.wikipedia.org/wiki/Scheme_progamming_language и http://en.wikipedia.org/wiki/Actor_model).

А вообще, термин "агент" становится слишком перегруженным. Есть FIPA-агенты, которые очень крупные (агент -- это приложение) и используют специальные языки для взаимодействия. Поскольку агенты в SObjectizer гораздо мельче, поэтому я предпочитаю говорить о работе в SObjectizer как о микроагентном программировании. Но все же агенты в SObjectizer оказываются более крупными (с состояниями и пр.), чем агенты в PPL. В этой связи агентов из PPL можно обзывать наноагентами

Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

R>Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

Ну перспективы Scala как промышленного языка программирования у меня уже который год вызывает сомнения.

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

E>Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

Вообще я хотел предложить такой вариант. Но надо, конечно, учитывать, что несмотря на то, что основные поставщики компиляторов скорее всего выпустят первые С++0х реализации через несколько месяцев после официального выхода стандарта, тем не менее более-менее стабильные реализации скорее всего появятся только через несколько лет (особенно это касается MSVC и ICC, gcc скорее всего сможет сделать это раньше). Плюс к этому первая волна С++0х докатится не только до ранних адоптеров тоже скорее всего года через 2-3.

Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.

R>>Да и для управляемого кода не так много промышленных библиотек, я не знаю получили ли какое-то промышленное распространение библиотеки типа .NET Agents или как она там называлась... не помню, или Scala Agents.

E>Ну перспективы Scala как промышленного языка программирования у меня уже который год вызывает сомнения.

Именно!
Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

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

E>>Так же хочется сказать, что появление C++0x может открыть перед SObjectizer5 новые возможности. В частности lambda-функции. Нужно будет посмотреть. Имхо, вполне можно проектировать SO5 с расчетом именно на C++0x.

R>Вообще я хотел предложить такой вариант. Но надо, конечно, учитывать, что несмотря на то, что основные поставщики компиляторов скорее всего выпустят первые С++0х реализации через несколько месяцев после официального выхода стандарта, тем не менее более-менее стабильные реализации скорее всего появятся только через несколько лет (особенно это касается MSVC и ICC, gcc скорее всего сможет сделать это раньше). Плюс к этому первая волна С++0х докатится не только до ранних адоптеров тоже скорее всего года через 2-3.

Все это не так страшно. Разработка SO5 стартует все равно не раньше 2009 и займет изрядное время даже если какой-нибудь человек будет ею заниматься в режиме full-time. Даже мы не сможем сразу же использовать SO5 в production-системах -- потребуются обкатка первых версий SO5 на каких-то менее критичных проектах. В таких условиях можно будет просто взять какой-то один компилятор и какую-то одну ОС для предварительных работ над SO5. А когда появится достаточное количество нормально поддерживающих C++0x компиляторов, можно будет серьезно взятся за кроссплатформенность.

R>Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.

Пока меня больше всего интересуют именно лямбды. Для многопоточности, вероятно, придется пользоваться какими-то библиотеками вроде ACE или Poco.

R>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

Если чесно, то не знаю. У меня для работы есть SObjectizer

И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

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

E>Все это не так страшно. Разработка SO5 стартует все равно не раньше 2009 и займет изрядное время даже если какой-нибудь человек будет ею заниматься в режиме full-time. Даже мы не сможем сразу же использовать SO5 в production-системах -- потребуются обкатка первых версий SO5 на каких-то менее критичных проектах. В таких условиях можно будет просто взять какой-то один компилятор и какую-то одну ОС для предварительных работ над SO5. А когда появится достаточное количество нормально поддерживающих C++0x компиляторов, можно будет серьезно взятся за кроссплатформенность.

Ну если так, то я думаю, что С++0х — это сильный козырь в рукаве. После выхода С++0х будет значительный недостаток "С++0х" библиотек для второй волны адоптеров. Т.е. вроде как и реализации С++0х достаточно окрепли и много всего вкусного и попробовать хочется, а нечего особо.
А старым библиотекам переходить на С++0х не особо. И переписывать много и обратную совместимость поддерживать надо.

R>>Хотя, конечно, полезных вещей там много — лямбды, вариадик-шаблоны, многопоточность и т.д.

E>Пока меня больше всего интересуют именно лямбды. Для многопоточности, вероятно, придется пользоваться какими-то библиотеками вроде ACE или Poco.

А для чего ты думаешь применять лямбды? Вроде как для функций обработки событий не особо кошерно получается...

R>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>Если чесно, то не знаю. У меня для работы есть SObjectizer

И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

Да, вакансия-то пока открыта

Вакансия завидная, и судя по первому впечатлению Microsoft не особо на неё претендует, уж больно у них как-то всё низкоуровнево.

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

R>Ну если так, то я думаю, что С++0х — это сильный козырь в рукаве. После выхода С++0х будет значительный недостаток "С++0х" библиотек для второй волны адоптеров. Т.е. вроде как и реализации С++0х достаточно окрепли и много всего вкусного и попробовать хочется, а нечего особо.
R>А старым библиотекам переходить на С++0х не особо. И переписывать много и обратную совместимость поддерживать надо.

Тут у меня какое-то непонимание. Разве C++0x -- это совсем другой язык? Какая-то совместимость же у C++0x с C++03 будет. Поэтому со временем просто возникнет момент, когда имеющийся C++ код будет адаптирован под новые версии компиляторов и все. Без доработки напильником, конечно, не обойдется. Но, надеюсь, слишком суровой она не будет.

R>А для чего ты думаешь применять лямбды? Вроде как для функций обработки событий не особо кошерно получается...

Как раз для обработки событий. Сейчас время от времени приходится создавать агентов, которые имеют всего одно состояние и одно-два-три события. Для них получается, что объем "обвязочного" кода, необходимого для SObjectizer, сравним или даже больше объема самих событий. Яркий пример: регистрируется какой-то агент (входящий коммуникационный канал), который может отослать сообщение об ошибки. По этому сообщению нужно остановить работу приложения. Для этого пишется маленький агентик, с одним событием -- реакцией на это сообщение. Этот мелкий агент регистрируется вместе с главным агентом кооперации.

По-хорошему, SO5 сможет для таких мелких агентов создавать обвязку самостоятельно. Программист только должен сказать -- вот лямбда, которая будет событием, вот инцидент для этой лямбды -- дальше давай сам. Удобство использования SO в таком случае уже должно повысится.

Далее есть пока еще смутные мечты о том, что подобным же образом можно будет предоставить пользователю возможность запрашивать у SO контекст для выполнения каких-то операций. Например, потребовалось отформатировать кусок данных и записать их в файл -- SO передается лямбда, которая это делает, а SO создает мелкого агентика, который получает контекст на какой-то рабочей нити SO и выполняет там эту лямбду. Т.е. какая-то реализация части fork из паттерна fork/join, только без стадии join

R>>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>>Если чесно, то не знаю. У меня для работы есть SObjectizer

И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

R>Да, вакансия-то пока открыта

На то и расчет!

R>Вакансия завидная, и судя по первому впечатлению Microsoft не особо на неё претендует, уж больно у них как-то всё низкоуровнево.

Не я не думаю, что разработка server-side на C++ -- это очень уж большая ниша. Больно уж много серьезных конкурентов: Java и .NET с мегабаксами от Sun и MS; Erlang, который сейчас super hot & sexy (на волне интереса к ФП, да и вообще); динамические языки вроде Ruby/Python/PHP, которые нашли себе серьезную нишу в области Web.

Но то, что для C++ место найдется -- я твердо уверен. Так что есть надежда, что место под солнцем мы себе найдем.

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

R>>Не смотря на то, что модель старая и хорошая, что сейчас может использовать обычный программист, какие есть известные библиотеки для нативного кода (не считая SObjectizer, который всё же больше рассчитан на русскоязычных пользователей)?

E>Если чесно, то не знаю. У меня для работы есть SObjectizer

И, по моему убеждению, задача состоит в том, чтобы сделать из SObjectizer что-то типа Erlang для C++.

В качестве иллюстрации мысли об актуального чего-то вроде Erlang для C++. Вот здесь Курилка дал ссылку на презентацию об использовании Erlang при разработки новой версии службы Delicious в Yahoo. И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

• Extremely good at fault-tolerant distributed applications.
• Ideal for messaging, communications and logging.
• Long running jobs with heavy monitoring requirements.
• Agile development process
• Many different interfaces
• RPC baked in for free

Пункты про Agile development и Many interfaces можно не рассматривать, т.к. у C++ с этим все нормально. Остаются fault-tolerance, message communication, monitoring и RPC. Хотя RPC вряд ли имеет смысл сочетать с messaging.

Теперь смотрим на проблемы Erlang-а (стр.32):

• There are documentation gaps.
• Hasn’t achieved critical mass yet.
• The community is thin.

и (стр.29):

• Erlang is very different.
• Engineers are usually stubborn.
• Not enough critical mass at Yahoo to be unquestionable.
• Tension was already high, adding a new language into the mix added uncertainty.

То получается, что внедрение Erlang-а в какой-нибудь существующий C++ проект будет сопровождаться необходимостью изучения совершенно нового подхода к программированию и, для многих, совершенно другого языка. Который плюс ко всему еще и динамически типизирован (что не многие любят). И который может быть N+1 языком в разработке, при том, что N уже превышает границы разумного

В то же время, если дать C++ разработчикам инструмент, который предоставляет хотя бы message communication и monitoring (а еще лучше построенные на их основе средства для fault-tolerance), то C++ разработчикам придется познакомиться только с новым подходом к разработке ПО. Не нужно будет учить новый язык. В их распоряжении останется статическая типизация. Не нужно будет внедрять в разработку новый язык и делать для него интеграцию с уже имеющимся кодом.

Конечно, у Erlang-а не отнимешь, например, горячую замену кода. Но, с другой стороны, Erlang хорош для распределенных систем, а это еще далеко не все, где C++ уже применяется и где еще может (и найдет) свое применение.

Вот как-то так. Блин, может пора уже себе блог заводить? А то таким тирадам вряд ли место в форуме...

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

E>И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

Насколько я понимаю, в Ерланге нет вообще ничего интересного, кроме полноценно реализованной модели актеров. Всей своей популярности он обязан только ей. Без неё это достаточно примитивный, тормозный, совсем не примечательный язык.

Просто так удачно получилось, что на момент появления широко доступных параллельных систем (многоядерных cpu) он фактически один имел практически пригодную реализацию адекватной модели параллельных вычислений. После того, как до людей начало доходить, что ручное создание потоков с ручной синхронизацией — это неадектватное решение, интерес к нему подскочил, и вот уже крупные компании (Yahoo, Amazon) серъезно вкладываются в Erlang-разработку. Я уже от многих людей слышал, даже от сисадмина, далекого от программирования — типа «erlang это такой язык с крутой параллельностью». Сейчас какой-то hype пошел насчет ерланга.

А ведь в нем как в _языке_ ничего нет для параллельности, более того, другой язык + actors легко может быть более удобным, более быстрым и т.д. имея точно такую же «крутую параллельность». Любая система, реализующая эмуляцию actors на многоядерном процессоре, автоматически получит почти все преимущества Erlang.

Копировать Erlang смысла точно нет — что там копировать? Зато я вот уже при разработке на Objective-C и .Net столкнулся с необходимостью такой выч.машины, и скоро видимо в C++ захочется.

Здравствуйте, Кодёнок, Вы писали:

E>>И хоть в самом начале сказано, что по большей части разработка была выполнена на C++, презентация дает читателю понять, что Erlang -- рулез форева (шутка). Так вот, в качестве преимуществ Erlang-а приводятся (стр.31):

Кё>Насколько я понимаю, в Ерланге нет вообще ничего интересного, кроме полноценно реализованной модели актеров. Всей своей популярности он обязан только ей. Без неё это достаточно примитивный, тормозный, совсем не примечательный язык.

Вот уж не думал, что мне придется выступать в качестве адвоката Erlang-а, да еще в обсуждении разработки, которая (по моим соображениям) должна быть конкурентом Erlang-a

Главное достоинство Erlang-а в том, что он очень хорошо подогнан под реализацию идей его создателей (Джо Армстронга со товарищи) о том, как должно разрабатываться ПО с высокими требования к надежности, отказоустойчивости о доступности.

Множество мелких процессов и обмен сообщениями -- это средство для обеспечения оказоустойчивости. Падение процесса -- это всего лишь падение одного процесса. Shit happens и с этим нужно считаться. Erlang считается с этим посредством мелких процессов, не имеющих разделяемых данных между собой. Обмен сообщениями -- это необходимая (при этом простая и, одновременно, мощная) форма взаимодействия процессов.

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

Функциональный подход -- это так же продолжение средств обеспечения отказоустойчивости и надежности. Во-первых за счет того, что мелкий процесс, в котором нет побочных эффектов гораздо проще и, как следствие, надежнее. Во-вторых, когда все состояние процесса передается из функции в функцию в виде параметров, возникает простая возможность горячено обновления кода процесса. Например, если процесс состоит из главного цикла выборки сообщений, то на очередной итерации, после возврата из функции обработки какого-то сообщения, тело главного цикла может быть уже совершенно другим.

В эту же сторону и динамическая типизация. Замена кода в приложении с динамической типизацией (будь то Erlang, Python или Ruby) выполняется гораздо проще, чем в приложениях со статической типизацией.

Так что по-отдельности, может быть, в Erlang-е и нет ничего выдающегося, зато как удачно выполненая компиляция разных идей, направленных на достижение вполне конкретных целей -- разработки отказоустойчивого ПО для телекома -- он выглядит весьма неплохо.

Кё>Просто так удачно получилось, что на момент появления широко доступных параллельных систем (многоядерных cpu) он фактически один имел практически пригодную реализацию адекватной модели параллельных вычислений. После того, как до людей начало доходить, что ручное создание потоков с ручной синхронизацией — это неадектватное решение, интерес к нему подскочил, и вот уже крупные компании (Yahoo, Amazon) серъезно вкладываются в Erlang-разработку. Я уже от многих людей слышал, даже от сисадмина, далекого от программирования — типа «erlang это такой язык с крутой параллельностью». Сейчас какой-то hype пошел насчет ерланга.

На самом деле вызывает очень большое уважение то, как разработчики Erlang-а на протяжении больше чем 20 лет (разработка Erlang, если не ошибаюсь, началась в 1986) не изменяли своим идеям и не забросили свои наработки. Так что имеющийся сейчас hype и, может быть, некоторый over use, ими вполне заслужен -- они его долго ждали.

Что до вкладывания денег в Erlang разработки, так здесь, может быть, срабатывает тот же фактор, что и для RubyOnRails. На какой-то момент стало понятно, что существующие подходы к созданию определенного класса Web-приложений (для RoR -- это "бюджетные", мелкие сайты) не годятся, программистам нужно было что-то другое, заточенное под их конкретные нужды. Вот RoR и выстрелил. Erlang, насколько я понимаю, сейчас пытаются применять на другой стороне спектра Web-приложений -- больших, сильно нагруженных, с высокими требованиями к надежности и маштабируемости. Видимо, Ынтырпрайзный Java настолько задолбал многих, что люди пробуют новые подходы. И Erlang, который уже зарекомендовал себя в телекоме с высочайшими требованиями к отказоусточивости, надежности и масштабировании, выглядит вполне обоснованным выбором.

Нужно еще добавить сюда возросший в последнее время интерес к функциональному программированию. Мол очередной кризис в производстве ПО, существующие подходы (то бишь ООП) не катят, срочно нужна новая silver bullet. Да тут еще и multicore массовый на голову свалился, а отцы-основатели ФП говорят, что функциональный код изначально распаралелливается, и бла-бла-бла... И тут оказывается (сюрприз, сюрприз!), что Erlang, пожалуй, один из самых успешных функциональных языков. И что на Erlang-е написано чуть ли не больше, чем на всех остальных функиональных языках вместе взятых (один только объем Erlang-овского кода для AXD301 чего стоит -- 1.2 миллиона строк кода). Вот и появился hype.

Кё>А ведь в нем как в _языке_ ничего нет для параллельности, более того, другой язык + actors легко может быть более удобным, более быстрым и т.д. имея точно такую же «крутую параллельность». Любая система, реализующая эмуляцию actors на многоядерном процессоре, автоматически получит почти все преимущества Erlang.

Мне кажется, что Erlang вообще не задумывался как язык для обеспечения параллельности в смысле HPC или оптимальной загрузки многоядерных процессов. Архитектура его приложений, состоящих из тысяч (десятков или сотен тысяч) процессов, предназначена совсем для других целей -- надежность и отказоустойчивость любой ценой. И поэтому существуют обоснованные, на мой взгляд, сомнения, что системы на базе статически-типизированных языков (вроде C++/Eiffel или даже управляемых JVM/.NET) способны предоставить разработчикам такие же возможности по разбиению приложения на тысячи мелких процессов и горячему обновлению кода.

Кё>Копировать Erlang смысла точно нет — что там копировать?

Мне, в первую очередь, хочется позаимствовать оттуда идею контроля процессов друг за другом, и процессов супервизоров, осуществляющих контроль и перезапуск упавших процессов.

А вообще я считаю, что Erlang получился очень хорошим языком, заточенным под конкретные нужды -- server-side с отказоустойчивостью и горячей заменой кода. В этом как его достоинство, так и его проблема. А то, что для Erlang-а проблема -- это возможность для SObjectizer и аналогичных фреймворков:
— в C++ нельзя делать приложения, состоящие из десятков тысяч процессов. Зато можно делать приложения из десятков, сотен тысяч, а то и миллионов агентов;
— в C++ растрел памяти может привести к краху всего приложения, в Erlang-е это невозможно. Но, если C++ приложение написано нормально, то может оказаться вполне достаточным поддержки рестарта проблемных агентов (например, выпускающих наружу свои исключения);
— в C++ можно достичь очень высокой скорости работы, чего в Erlang не будет в принципе (разве что за счет переписывания каких-то кусков на C/C++);
— в C++ агентно-ориентированный фреймворк можно внедрить в уже существующее C++ приложение. При этом не потребуется переучивание разработчиков на новый язык и не потребуется изменение архитектуры приложения для встраивания в него интерпритатора Erlang-а;
— в C++ агентно-ориентированные фреймворки могут применяться для самого широкого спектра задач: начиная от мелких утилит, обслуживающих какой-нибудь подключеный к компьютеру девайс (SmartCard-ридер или GSM-модем), и заканчивая большими, распределенными телеком- или банковскими системами.

Так что копировать весь Erlang действительно нет смысла. А вот учесть его опыт и сильные стороны в C++ных разработках, имхо, необходимо.

От:	eao197	http://eao197.blogspot.com
Дата:	23.09.08 12:17
Оценка:

	От:	zaufi
	Дата:	23.09.08 14:09
	Оценка:	32 (4)

От:	jazzer	Skype: enerjazzer
Дата:	23.09.08 17:08
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	23.09.08 19:03
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	23.09.08 19:22
Оценка:

	От:	Кодёнок
	Дата:	26.09.08 10:23
	Оценка:	40 (1)

От:	remark	http://www.1024cores.net/
Дата:	02.10.08 18:28
Оценка:

	От:	alsemm
	Дата:	24.09.08 11:23
	Оценка:

	От:	bsivko
	Дата:	25.09.08 21:53
	Оценка: