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

это всё хорошо работает, но есть ужасная проблема:

состояния непрерывно сохраняются и нужно както их чистить, т.е. удалять те которые никому не нужны

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

тут еще открытый вопрос кто должен хранить эти состояния

есть решение для того случая?

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

K>есть решение для того случая?
Самый простой способ — разделение на персистентные и agent-owned данные.
Первые живут постоянно, вторые живут и умирают вместе с агентом, при восстановлении агента вычисляются заново. Данные, пересылаемые между агентами по определению immutable, поэтому совместного владения не требуется.

Конкретный подход зависит от используемого актор-фреймворка. Если фреймворка нет — это только начало проблем, мои соболезнования.

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

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

K>>есть решение для того случая?
S>Самый простой способ — разделение на персистентные и agent-owned данные.
S>Первые живут постоянно, вторые живут и умирают вместе с агентом, при восстановлении агента вычисляются заново. Данные, пересылаемые между агентами по определению immutable, поэтому совместного владения не требуется.

S>Конкретный подход зависит от используемого актор-фреймворка. Если фреймворка нет — это только начало проблем, мои соболезнования.

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

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

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

K>есть решение для того случая?

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

Пусть у объектов есть уникальные идентификаторы. Когда состояние объекта меняется, то идентификатор объекта остается неизменным. И ссылаться надо не на конкретное сохраненное состояние объекта, а на идентификатор объекта. По которому легко находится его последнее известное сохраненное состояние. Я все предыдущие можно смело удалить.

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

K>нужно както их чистить, т.е. удалять те которые никому не нужны
K>есть решение для того случая?

На выбор: либо garbage collector либо reference counting (std::shared_ptr например).

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

Pzz>Пусть у объектов есть уникальные идентификаторы. Когда состояние объекта меняется, то идентификатор объекта остается неизменным. И ссылаться надо не на конкретное сохраненное состояние объекта, а на идентификатор объекта. По которому легко находится его последнее известное сохраненное состояние. Я все предыдущие можно смело удалить.

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

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

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

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

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

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

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

K>это всё хорошо работает, но есть ужасная проблема:

K>состояния непрерывно сохраняются и нужно както их чистить, т.е. удалять те которые никому не нужны

K>1. по времени создания нельзя, ктото может ссылать на чтото очень старое
K>2. запоминать агентов-рефереров вместе сохраненным состоянием бесполезно — от исчезнувшего агента это поможет, а от глючного — нет, потому что глючный агент будет всё еще присутствовать но забудет убрать ссылку

K>тут еще открытый вопрос кто должен хранить эти состояния

K>есть решение для того случая?

А цикл жизни агентов каков? Они "вечные" или работают месяц-полгода-год? Я бы плясал от времени жизни агенты, и, как уже ниже посоветовали, делал бы garbage collector.

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

S>Я бы плясал от времени жизни агенты, и, как уже ниже посоветовали, делал бы garbage collector.

Garbage collecton на диске то еще занятие.

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

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

S>>Я бы плясал от времени жизни агенты, и, как уже ниже посоветовали, делал бы garbage collector.

W>Garbage collecton на диске то еще занятие.

Тут от настоящего GC одно название. Пройтись по файлам исчезнувших навсегда агентов и удалить.

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

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

K>>есть решение для того случая?
S>Самый простой способ — разделение на персистентные и agent-owned данные.
S>Первые живут постоянно, вторые живут и умирают вместе с агентом, при восстановлении агента вычисляются заново. Данные, пересылаемые между агентами по определению immutable, поэтому совместного владения не требуется.

S>Конкретный подход зависит от используемого актор-фреймворка. Если фреймворка нет — это только начало проблем, мои соболезнования.

в самом генерализованном виде решения похоже нет

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

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

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