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

N>Ну мне сложно подобрать иной термин, как "убийство проекта", для того, что мне пришлось выкинуть Erlang-версию и срочно перегнать приблуду (специализированный прокси) на C++.
N>Появился гимор с управлением памятью, зато исчез — с неуправляемыми заклинами всего приложения под нагрузкой.

это до следующего уровня нагрузки.
дропать сообщеньки надо. ну, если нет больших проблем с постановкой сообщенек самому себе, тогда совсем всё плохо.

N>>>Лев Валкин (lionet@), например, строил демпферы на точках передачи между нодами, оповещая их о состоянии приёмных процессов. У него целый фреймворк был для этого.
F>>ага, дистрибушон — слабое место.
N>Там был не то чтобы distribution...

а зачем тогда? выравнивал нагрузку между нодами?

N>Не значит, но факт тот, что там отдельные кучи у каждого процесса.

да как бы и нет. если нужна память, процесс её берёт у VM, которая берёт её у системы.
память берётся чанками и освобождается в паре ситуаций.

F>>просто при передаче управления они выкидывают уже ненужное. и "общая куча" при этом тоже имеет возможность избавиться от лишнего.
N>Нет. GC срабатывает в каждом процессе отдельно и по превышению им количества так называемых reductions с прошлого старта GC. Reduction — это, грубо говоря, любая элементарная операция интерпретатора (один оператор выражения, один вызов функции, один простой матчинг-биндинг и т.п.) В последних релизах разделены поколения и полная сборка, но по-прежнему по процессам раздельно. Читайте начиная с process_flag(fullsweep_after).

да что-то ни разу не так.
память чистится либо при завершении процесса, либо с hibernate из gen_server'а.