Тема: (vlax-release-object) - Тонкости работы

> Администрации : прошу (если такое возможно) не разбивать тему, поскольку непонятность имеет общие корни.
Известно, что функцию надо применять при обращении к COM-объектам. Вопросов собственно два:
1. Насколько необходимо применять (vlax-release-object) при обращении к собственным COM-библиотекам? В "САПР на базе..." функция то используется, то нет. В том числе и на внутренние представления объектов када (то есть, то нет), и на dll (тоже самое)
2. Каковы условия освобождения объекта? (vlax-release-object) освобождает объект не сразу, каким образом можно гарантированно очистить память? Поскольку применить (vlax-object-released-p) невозможно - объект является локальной переменной. А множить копии стороннего класса совсем не хочется...

Re: (vlax-release-object) - Тонкости работы

> kpblc
На собственном опыте я пришел к выводу, что такие переменные с COM-объектами лучше держать глобальными. Тогда к ним можно будет подступиться по окончании работы (им еще не присвоен nil).
Если такие переменные все-таки локальные, то их и освобождать надо внутри той функции, где они были созданы.

Re: (vlax-release-object) - Тонкости работы

А если вообще нет переменной, в которой содержится указатель на объект? В Lisp это запросто может быть.
Вообще есть подозрение, что vlax-release-object в LISP попала "для чистоты идеи".
См. также http://dwg.ru/forum/viewtopic.php?t=619 … 79d0a2dfc2

Re: (vlax-release-object) - Тонкости работы

> ShaggyDoc
Когда переменной нет, то возможна утечка динамически выделяемой памяти. Если для VLA-объектов AutoCAD (они того же рода) это, может быть, не страшно, т.к. по окончании работы приложения на LISP сборщик мусора как-то сам функционирует, то для объектов других приложений отсутствие явного высвобождения вряд ли хорошо.
Может быть, Александр Ривилис что-то добавит?

Re: (vlax-release-object) - Тонкости работы

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

(vlax-release-object...    

делать

(setq obj nil) 

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

(vlax-release-object obj)
(setq obj nil) 

получаю стабильный результат.

Re: (vlax-release-object) - Тонкости работы

> Н.Н.Полещук
Мне (пока) не требуется такое. СОМ-объект требуется только в данной процедуре. Дальше он не используется. Естественно, что это просто конкретная задача. Что будет дальше - пока загадывать не берусь.

ShaggyDoc пишет:

Вообще есть подозрение, что vlax-release-object в LISP попала "для чистоты идеи".

В смысле - если есть обращение к сторонним объектам, их и очищать надо?

> Евгений Елпанов
Я проверил, (setq obj nil) не сработало. Хотя память не сильно утекает, но все равно, по меньшей мере неприятно.
А вот насчет (gc) что-то подзабыл... Пока не особо критична ее глобальность, а там посмотрим.
---
Всем спасибо за информацию.

Re: (vlax-release-object) - Тонкости работы

В общем, проверил по советам Евгения Елпанова. Память не очищается до конца:
до начала выполнения функции - 67,916 Мб
На момент выполнения метода - 68,024 Мб
После выхода из функции - 67,968 Мб
ACAD 2005, файл пустой.
Т.е. фактически потери не так уж и велики, казалось бы - 48 кб (почти размер скомпилированной dll), но если применять COM достаточно широко, память утечет как вода сквозь песок.

Re: (vlax-release-object) - Тонкости работы

В результате личных переговоров в Евгением выяснилось, что я поднял вопли, не до конца разобравшись в вопросе. В общем, проблема не в утечке памяти, а в ее выделении. Применение недокументированной в сегодняшней справке функции (vmon) и последующее применение (gc) показывает простое колебание выделенной памяти в некоторых пределах (проверялось на 1 000 повторов). Кстати, отказ от этих функций ничего принципиально не меняет. Т.е память не утекает, она просто резервируется виндой. И в этой памяти болтается указатель на СОМ-объект, похоже.
Связка (vlax-release-object) + (setq obj nil) нормально работает. Если отказаться от (setq obj nil), возможно наращивание объема выделенной памяти под кад.
Т.е. ничего особо страшного.

Re: (vlax-release-object) - Тонкости работы

Autodesk рекомендует:
1) использование (vlax-release-object) для внешних объектов (например, Excel'еских, Word'овских и т.д.) с последующим присвоеним переменной nil.
2) Активно испольщовать сборку мусора (gc), причем как после (vlax-release-object), так и до вызова первого метода внешнего объекта.
3) Не запускать VLIDE, так как если он запущен, то полного высвобождения объектов внешнего приложения не происходит и оно не завершится.

Re: (vlax-release-object) - Тонкости работы

Я разбирался с COM по литературе для Delphi. Там никакого высвобождения со стороны клиента не требуется. Не требуется и со стороны сервера.
Так сделал множество COM-dll, вызываемых из разных клиентов, в то числе из LISP. Ничего не ломается без высвобождения.
В интерфейсе IAcadObject нет никаких Free, Release.
Флаги и у IAcadObject, и у моих одинаковые
(4416) Dual OleAutomation Dispatchable
Тем не менее, в LISP многие высвобождают и объект Автокада. Зачем - непонятно. Его тут же придется создавать и будет получен тот же указатель.
В литературе о COM, основанной на С++ также указаний по освобождению не встретил, хотя там-то уж ожидалось. Встречаются правда, нехорошие намеки на то, что автоматизация (а именно ее мы применяем в LISP) изначально задумывалась для VB и потому, мол, в ней такие заморочки.
Возможно "использование (vlax-release-object) для внешних объектов (например, Excel'еских, Word'овских и т.д.)" необходимо именно для продуктов Microsoft? Все-таки они написаны не совсем так, как предписано другим.
Тройка vlax-create - vlax-release - обNilение, конечно не повредит. Но надо ли всегда высвобождать? Сомневаюсь. Что лучще - чуть-чуть памяти или потеря времени на повторное создание объекта?

Re: (vlax-release-object) - Тонкости работы

Возможно "использование (vlax-release-object) для внешних объектов (например, Excel'еских, Word'овских и т.д.)" необходимо именно для продуктов Microsoft? Все-таки они написаны не совсем так, как предписано другим.

Очень может быть. :) Никаких уточнений на этот счет Autodesk не делает.