Захотелось в Erlang'е множественных очередей. Или приоритетных.

[netch80]

Ибо когда A посылает толстый поток данных на B, B - на C, C захлёбывается и просит B прикрутить краник - посылать сообщение об этом бессмысленно. Нормальным ходом оно дойдёт чёрт знает когда, а выбирать по маске с линейным перебором очереди - прямой способ убить всё вокруг нагрузкой.

Все альтернативные способы кривы. Прокси-процесс с flow control - лишняя нагрузка на пересылке. Самым разумным показалась эмуляция глобальной переменной через специальный процесс и gen_server:call() к нему на каждые 100-1000 обработанных сообщений. Главное, чтобы этот процесс не сдох сам от нагрузки.

Ну и как это называется? ;(

Comments

[dbg.livejournal.com]

> Идея понятная и известная.

Угу. Я бы даже сказал, что это, простигосподи, design pattern.

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

Именно. Отдельный держатель базы. А чтоб его не зафлудить, он может флоуконтролить протокольную машину. И/или протокольный модуль может бэтчить апдейты.

> Пока "думатель" думает, базу нельзя править напрямую. Модуль протокола должен или тормозить на локе, или сложить изменение в очередь и уйти.

Можно лок, да. Можно snapshot копированием. А можно вспомнить, что у нас язык функциональный и на чистых структурах данных copy-on-write получается сам.

[netch80.livejournal.com]

> Можно лок, да. Можно snapshot копированием. А можно вспомнить, что у нас язык функциональный и на чистых структурах данных copy-on-write получается сам.

У кого получается, у кого нет. У Erlang'а такое copy-on-write работает только в пределах одного процесса. Между хипами процессов кросс-ссылок не может быть в принципе.

> Именно. Отдельный держатель базы. А чтоб его не зафлудить, он может флоуконтролить протокольную машину. И/или протокольный модуль может бэтчить апдейты.

Страшно звучит, но надо подумать.