Здравствуйте, neFormal, Вы писали:
N>>Процесс не может регулировать, что ему отправляется в mailbox. Mailbox один для сообщений всех типов и источников. При его большой длине синхронные взаимодействия начинают стоить пропорционально длине очереди каждое, а в сумме получается квадратичная зависимость. Некоторые действия даже по избавлению от данных (как gen_tcp:send) требуют обратного приёма сообщения, соответственно, там получается то же O(n^2). F>ну да, но чтобы это было убийством — ну фиг знает.
Ну мне сложно подобрать иной термин, как "убийство проекта", для того, что мне пришлось выкинуть Erlang-версию и срочно перегнать приблуду (специализированный прокси) на C++.
Появился гимор с управлением памятью, зато исчез — с неуправляемыми заклинами всего приложения под нагрузкой.
N>>Лев Валкин (lionet@), например, строил демпферы на точках передачи между нодами, оповещая их о состоянии приёмных процессов. У него целый фреймворк был для этого. F>ага, дистрибушон — слабое место.
Там был не то чтобы distribution...
N>>В Erlang — по умолчанию на процесс, кроме общей кучи на толстые бинари. При запуске GC процесса должно быть достаточно свободной памяти, чтобы сделать копию всех выживших данных. Отсюда конструкции с небольшим количеством очень толстых процессов имеют шанс убить целиком еноду.
F>откуда там отдельные gc? F>то, что процессы отдают память лишь в двух случаях передачи управления другим процессам, не значит, что у каждого по отдельному gc.
Не значит, но факт тот, что там отдельные кучи у каждого процесса.
F>просто при передаче управления они выкидывают уже ненужное. и "общая куча" при этом тоже имеет возможность избавиться от лишнего.
Нет. GC срабатывает в каждом процессе отдельно и по превышению им количества так называемых reductions с прошлого старта GC. Reduction — это, грубо говоря, любая элементарная операция интерпретатора (один оператор выражения, один вызов функции, один простой матчинг-биндинг и т.п.) В последних релизах разделены поколения и полная сборка, но по-прежнему по процессам раздельно. Читайте начиная с process_flag(fullsweep_after).
