Нужно разработать сервер (IVR app), который должен работать 7х24. Нужна так же кроссплатформенность. Какие frameworks лучше для soft-realtime и что бы не было большой фрагментации памяти. Есть варианты, но хотелось бы услышать ваше мнение:


1) использовать STL+boost и custom allocators (например heap-layers).
2) не использовать STL вообще, только минимальное ядро C++ без exceptions. Здесь рассматриваю Apache Portable Runtime (APR) framework и его pool механизм как custom allocator.
3) использовать ACE. Выглядит страшно, но ACE был разработан как раз для таких целей. Документации~--- кот наплакал. :(
4) POCO? внутрях использует активно STL.

есть ли другие идеи?
спасибо.

Мне STL+boost нравятся, хотя это сильно зависит от команды.

Erlang

+1

:)

на ACE документации достаточно, даже на русском - 2-хтомник C++ Network Programming, ну и Programming ACE, и несколько книг из серии Patter-Oriented Software Architecture

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

> на ACE документации достаточно, даже на русском - 2-хтомник C++ Network Programming, ну и Programming ACE, и несколько книг из серии Patter-Oriented Software Architecture

только вот она - документация в виде 3х книг - устарела года на четыре-пять да и тогда покрывала далеко не все механизмы ACE. это с учётом постоянного потока коммитов за эти годы. то же, что генерируется из комментариев сложно именовать гордым словом "документация" :-/

// wbr

> а идея с бустом хороша, но качество программистов должно быть высоким, как показала практика

качество же программистов под ACE должно быть или *очень* высоким причём с живим и актуальным опытом разработки именно под этим толкитом достаточно больших систем (>> 100k строк кода) или же про 24x7 придётся забыть.

// wbr

ps: ну и ещё неплохо было бы услышать что-то более конкретное. что значит "большая фрагментация памяти"? у STL она большая? а у штатного libc malloc? а у врапера APR над malloc? а как вы её измеряете или планируете измерять, если уж разговор зашёл о количественной оценке? и какая цифра вас устроит а какая уже нет? опять же, что именно она отображает эта цифра?

// wbr

> ну и ещё неплохо было бы услышать что-то более конкретное. что значит "большая фрагментация памяти"?

ВотЪ. И вообще мне кажется, что заданные вопросы к реальности имеют весьма косвенное отношение :) Хотя интересно было бы услышать, чем насолили исключения.

> есть ли другие идеи?

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

// wbr

> IVR app

неужели для "IVR app" все это необходимо?

> неплохо было бы услышать что-то более конкретное. что значит "большая фрагментация памяти"? у STL она большая? а у штатного libc malloc? а у врапера APR над malloc? а как вы её измеряете или планируете измерять, если уж разговор зашёл о количественной оценке? и какая цифра вас устроит а какая уже нет? опять же, что именно она отображает эта цифра?

цифр пока нет, даже прикидок. Но в google много информации о том почему нужно использовать custom allocators (статьи Alexandrescu, heap-layers на все случаи) если нужны эти 24х7. Хорошо, докажите обратное. Почему же почти все soft real-time проекты (eg. ip voice/video streaming apps, PBX soft (asteriks, freeswitch), apache webserver etc.) используют pooling, a не heap напрямую?

> Хотя интересно было бы услышать, чем насолили исключения.

Они просто там нафиг не сдались. Речь идет о IVR под высокой нагрузкой.

> тогда непонятно, а зачем вам C++ :-?

потому как удобно создать свой framework со своими стандартными интерфейсами и модулями. Нужна поддержка железа от разных вендоров с разными API. А на C городить все это слишком долго, а костыли ненадежны. От C++ нужно только инкапсуляция, наследование и полиморфизм. Исключения не нужны.

Подумал, и решил обернуть APR. Тесты покажут.

> цифр пока нет, даже прикидок. Но в google много информации о том почему нужно использовать custom allocators (статьи Alexandrescu, heap-layers на все случаи) если нужны эти 24х7.

Александреску - это прекрасно. это даже замечательно. но ни в коей мере не отменяет собственный живой опыт. его хорошо бывает почитать на ночь перед сном но на утро welcome to the real life.

> Хорошо, докажите обратное.

математически? и не подумаю. с практической же точки зрения в десятке законченных проектов разного размера и разной степени сложности но которые объединяет требование к работоспособности на протяжении неограниченного периода времени без вмешательства оператора i.e. по схеме "поставил-настроил-запустил-забылнавсегда" ни разу не понадобился кастомный heap allocator бо всё и так прекрасно работает и с libc и с STL и с boost и иже с ними. и выбор того или иного тулкита или фреймворка никогда не плясал от столь странных в реальной жизни предпосылок.

> Почему же почти все soft real-time проекты (eg. ip voice/video streaming apps, PBX soft (asteriks, freeswitch), apache webserver etc.) используют pooling, a не heap напрямую?

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

// wbr

> Подумал, и решил обернуть APR. Тесты покажут.

у APR есть один минус - отвратительная документация. точнее, её фактическое отсутствие. чего не скажешь про STL или boost. да и попытка смешать в одну кучу сугубо C-шный тулкит с основным дизайном на C++ мягко говоря вызывает некоторые сомнения.

// wbr

> у APR есть один минус - отвратительная документация. точнее, её фактическое отсутствие. чего не скажешь про STL или boost. да и попытка смешать в одну кучу сугубо C-шный тулкит с основным дизайном на C++ мягко говоря вызывает некоторые сомнения.

Хорошо, подумаю еще раз :)

Если opensource проекты использующие ACE, у которых код читабельный и можно использовать его как reference. Стоит ли вообще заморачиваться с АCE?

> используют pooling

pooling - в apache/httpd с самого начала
и там же до сих пор, поэтому можно обойтись и без APR.
Красивый механизм позволяющий избежать mem.leaks
Рекомендую написать свой оператор new, который бы делал
allocation in request->pool => получаем автоматический
garbage collector. Все обьекты созданные во время HTTP requesta
будут автоматически удалятся после его окончания

s/Если/Есть ли/

> Все обьекты созданные во время HTTP requesta будут автоматически удалятся после его окончания

Да, это пригодиться для session management.

> APR есть один минус - отвратительная документация.

есть она где-то ...
я сижу в ейном devel-liste уже лет 5, могу поискать ..

> Если opensource проекты использующие ACE, у которых код читабельный и можно использовать его как reference.

лично я такого не встречал. что впрочем не означает, что его действительно не существует.

> Стоит ли вообще заморачиваться с АCE?

сложный вопрос. если у вас планируется большой и толстый проект [миллионы и миллионы строк], который будет тянуться и тянуться годами и у вас нет жёстких сроков по времени и у вас есть достаточное количество квалифицированных C++ программистов с богатым опытом, которые готовы тратить [массу] своего времени проводя его в ковыряниях в достаточно тяжелых внутренностях ACE потому что вот так вот прости TP_Reactor нифига не работает и валит всё в корку но если сделать вот так то вроде как не валит [хер знает по чему на самом деле но факт] и если вы ярый поклонник экспериментов по внедрению патернов в реальную жизнь любой ценой..

// wbr

> у вас нет жёстких сроков по времени и у вас есть достаточное количество квалифицированных C++ программистов с богатым опытом, которые готовы тратить [массу] своего времени проводя его в ковыряниях в достаточно тяжелых внутренностях ACE потому что вот так вот прости TP_Reactor нифига не работает и валит всё в корку но если сделать вот так то вроде как не валит [хер знает по чему на самом деле но факт] и если вы ярый поклонник экспериментов по внедрению патернов в реальную жизнь любой ценой..

мдаа... все желание пропало. :)

>требование к работоспособности на протяжении неограниченного периода времени без вмешательства оператора i.e. по схеме "поставил-настроил-запустил-забылнавсегда" ни разу не понадобился кастомный heap allocator бо всё и так прекрасно работает и с libc и с STL и с boost и иже с ними

Под линуксом с фрагментацией дело обстоит похуже чем на винде. BTW даже на винде до сих пор не задепрекейтили compacting heap использовавшийся на win16 в виде GlobalAlloc()/GlobalLock()/GlobalUnlock() и заявили о совместимости этих функций с Вистой.

Для soft realtime лично я бы использовал преаллоцированную память.

> мдаа... все желание пропало. :)

ну это лишь моё мнение, не более того.

с точки зрения скажем community ACE замечательный проект: в их рассылках крутится много квалифицированных людей, они достаточно шустро исправляют баги и без проблем и лишней волокиты принимают внешние багфиксы, сам по себе Дуглас Шмидт весьма коммуникабельный и цивилизованный товаристч с которым легко общаться [в противовес скажем Тео]. в общем, поддержку при желании найти не проблема.

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

// wbr

> Под линуксом с фрагментацией дело обстоит похуже чем на винде. BTW даже на винде до сих пор не задепрекейтили compacting heap использовавшийся на win16 в виде GlobalAlloc()/GlobalLock()/GlobalUnlock() и заявили о совместимости этих функций с Вистой.

ну MS Windows AFAIU не рассматривается в этом вопрос как потенциальная платформа со всеми вытекающими. или я что-то упустил?

> Для soft realtime лично я бы использовал преаллоцированную память.

// wbr

>ну MS Windows AFAIU не рассматривается в этом вопрос как потенциальная платформа со всеми вытекающими. или я что-то упустил?

Вы AFAIK оффтопик-юзер? Я думал, вы про свой опыт рассказываете.

>> Для soft realtime лично я бы использовал преаллоцированную память.

>// wbr

По моему ничего сложного. Конечно, все зависит от сложности системы.

Зачем тебе realtime для IVR?

> Зачем тебе realtime для IVR?

_soft-realtime_. Вы случайно realtime c быстротой реакции отклика не путаете?

Не путаю, soft-realtime тоже realtime.

Я действительно не понимаю зачем он нужен для IVR.

>> Зачем тебе realtime для IVR?

>_soft-realtime_. Вы случайно realtime c быстротой реакции отклика не путаете?

Распознавание звука - realtime задача. Переадресация звонков - не realtime.

ACE - это CORBA что ль? столько шуму было лет ~10 назад ...
все в свисток ушло

> Вы AFAIK оффтопик-юзер?

верно.

> Я думал, вы про свой опыт рассказываете.

и это то же верно.

что не мешает мне по крайней мере последние 10 лет писать исключительно под *NIX системы. так уж сложилось.

// wbr

> Переадресация звонков - не realtime.

ну, хоцца человеку, чтобы было, как в realtime :))

> ACE - это CORBA что ль? столько шуму было лет ~10 назад ...

нет, ACE - это Advanced Communication Environment. межсистемный в плане переносимости фреймворк над стандартными сервисами, предоставляемыми системой. к CORBA же имеет отношение т.н. TAO - реализация OMG CORBA на базе ACE. но сама по себе ACE к корбе отношения не имеет :)

// wbr

> Переадресация звонков - не realtime.

Переадресация звонков с Распознавание речи - достойная задачка :))

>столько шуму было лет ~10 назад ... все в свисток ушло

В SOAP и EJB скорее.

>> Переадресация звонков - не realtime.

>Переадресация звонков с Распознавание речи - достойная задачка :))

На типовой IVR распознается тоновый сигнал 2 my mind. IVR с рапознаванием речи - более новая мода.

> ну, хоцца человеку, чтобы было, как в realtime :))

Смешного здесь ничего нету. Нужна интеграция IVR c TTS & ASR, нужен соnferencing (+ видео). Будет также использоваться SIP-T, для SS7 over IP.

SIP/VOIP - чтот много шуму вокруг этого. new Skype рожаете?

>SIP/VOIP - чтот много шуму вокруг этого. new Skype рожаете?

ога. oranges vs apples. :D

странно, а что, поклонники тёмной силы все поголовно ушли в отпуск? как-то непривычно общаться без выкриков "плюсы гавно хаскель рулит!". это точно лор :-?

// wbr

пускай резвятся в Talks. Здесь они как бы не нужны,

А для чего конкретно здесь нужен realtime и зачем SIP-T?

Здесь, по-моему, больше подойдёт h.323.

> ни разу не понадобился кастомный heap allocator бо всё и так прекрасно работает и с libc и с STL и с boost и иже с ними.

Год назад на грабли с фрагментацией в STL наступали. Кастомный аллокатор помог выявить проблему, но не решить. Вылечилось переписыванием программы без STL, оказалось проще, чем правильный кастомный аллокатор писАть.

Задача -- HPC, целые числа. За неделю перемалывала в пыль порядка 10 гиг оперативки, хотя ликов не было.

> Задача -- HPC, целые числа. За неделю перемалывала в пыль порядка 10 гиг оперативки, хотя ликов не было.

"перемалывала в пыль" это в смысле khm.. буквально :-?

// wbr

> За неделю перемалывала в пыль порядка 10 гиг оперативки, хотя ликов не было.

Народ жаждет подробностей.

16 гиг оперативки, 6 занято данными, остальное, типа, фрагментировано. Долго все отлавливали, учитывали; потом подтвердилось. Хорошо, задача не шибко толстая была, переписали движок быстренько.

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

> 16 гиг оперативки, 6 занято данными, остальное, типа, фрагментировано. Долго все отлавливали, учитывали; потом подтвердилось. Хорошо, задача не шибко толстая была, переписали движок быстренько.

тут я ничего не могу прокомментировать - не видел. впрочем, было так было.

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

а вот по поводу FF есть у меня некоторые сомнения. этот процесс как-то моделируется в лабораторных условиях? в смысле простенький тест, который бы на манер FF явно бы показывал, что при безликовом использовании памяти внутри программы VMA тем не менее растёт растёт и растёт. IMHO заставлять для проверки гонять FF сутками а тем более потом разбираться в нём что и почему - это через чур жестоко :)

// wbr