Re[7]: скриптовый движок
От: Юнусов Булат Россия  
Дата: 18.10.06 18:44
Оценка: 7 (1)
Здравствуйте, Sergey, Вы писали:

S>Не, серьезно — гарбаж коллектор не дает никаких преимуществ перед подсчетом ссылок для имплементации нетекущего rpc с обрывами связи. В обоих случаях на сервере потребуется организовать некий периметр, на котором придется хранить указатели на используемые удаленными клиентами объекты в случае с GC (чтоб GC их не поприбивал) или "инкременторы рефкаунта" (да хоть те же boost::shared_ptr или boost::weak_ptr) в случае с подсчетом ссылок. И при обрыве связи в обоих случаях придется эти сущности из периметра удалять. Разница минимальна.


Понял твою мысль.
Я поцитирую маленько:

Идиомы подсчета ссылок .. являются упрощеной идиомой уборки мусора... Однако, алгоритмы основанные на подсчете ссылок, не позволяют освобождать память циклических структур данных без применения механизмов рекурсивного сканирования, требующих больших затрат ресурсов.
В высокоуровневых объектно-ориентированных языках применяются особые схемы уборки мусора, избавленные от этого ограничения, но в них редко используется подсчет ссылок. Методы, не требующие подсчета ссылок, также лучше подходят для встроенных систем реальногго времени, в которых исключительные события могут стать причиной каскадных операций восстановления когда освобождение памяти затруднено. Если процесс становится неуправляемым и нуждается в аварийном завершении, возможно у него не будет возможностей выполнить свои деструкторы. Если он использует объкты с подсчетом ссылок совместно с другими процессами, то счетчики ссылок таких объектов никогда не уменьшатся до нуля, и эти объекты никогда не будут освобождены. В свете таких сбоев аудит памяти отличается большей гибкостью в отношении возврата освободившихся рсурсов, чем подсчет ссылок.


Заметим, книга 1992 года выпуска, тогда не то что дотнета, com-а то не было.

А про обрыв — это я спроецировал нечаянно мыслю Коплейна на свой прошлый проект — распределенная rts для автоматизации нефтянки — там традиционно используется DCOM/OPC, и сопуствующий секс
Re[8]: скриптовый движок
От: Sergey Россия  
Дата: 19.10.06 07:39
Оценка: +1
Здравствуйте, Юнусов Булат, Вы писали:


> S>Не, серьезно — гарбаж коллектор не дает никаких преимуществ перед подсчетом ссылок для имплементации нетекущего rpc с обрывами связи. В обоих случаях на сервере потребуется организовать некий периметр, на котором придется хранить указатели на используемые удаленными клиентами объекты в случае с GC (чтоб GC их не поприбивал) или "инкременторы рефкаунта" (да хоть те же boost::shared_ptr или boost::weak_ptr) в случае с подсчетом ссылок. И при обрыве связи в обоих случаях придется эти сущности из периметра удалять. Разница минимальна.

>
> Понял твою мысль.
> Я поцитирую маленько:
>

> Идиомы подсчета ссылок .. являются упрощеной идиомой уборки мусора... Однако, алгоритмы основанные на подсчете ссылок, не позволяют освобождать память циклических структур данных без применения механизмов рекурсивного сканирования, требующих больших затрат ресурсов.
> В высокоуровневых объектно-ориентированных языках применяются особые схемы уборки мусора, избавленные от этого ограничения, но в них редко используется подсчет ссылок.


С этим никто не спорит. Правда, я бы еще, применительно к циклическим структурам данных, упомянул бы слабые ссылки.

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


Насчет риалтаймов я вообще не в курсе.

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


Это тоже решается введением "периметров" aka списков хэндлов. Просто, при межпроцессном общении, помимо собственно счетчиков ссылок надо знать еще и владельцев ссылок.

> Заметим, книга 1992 года выпуска, тогда не то что дотнета, com-а то не было.


Хэндлы тоже не вчера выдумали. И файлы, равно как и другие объекты, в любой нормальной операционке вполне себе закрываются, даже если открывший его процесс издох, не вызвав CloseHandle или как оно там в конкретной ОС называется.

>

> А про обрыв — это я спроецировал нечаянно мыслю Коплейна на свой прошлый проект — распределенная rts для автоматизации нефтянки — там традиционно используется DCOM/OPC, и сопуствующий секс

Сейчас я начну ругаться матом и на DCOM, и на OPC
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.