@Ygg

Те COM-ы, с которыми я имел дело, всегда делались в виде DLL (или AX, что по структуре идентично, отличие только в расширении). Такая DLL имеет несколько стандартных точек входа, которые используются для создания лежащих в ней COM-объектов.

В реестре прописаны секции с именем равным GUID COM-объектов. В каждой такой секции лежит имя dll-файла, в котором лежит реализация данного COM-объекта.

Когда пользовательская программа вызывает CoCreateInstance(<нужный GUID>) для создания объекта локально, то выполняется поиск GUID-а по реестру компа. Найдя GUID определяется имя его DLL. Данная DLL подгружается в пользовательский процесс и через стандартные точки входа создаётся новый объект.

Если же объект создаётся не локально, то процесс совсем иной. Локально создаётся прокси нужного объекта, а на сервер отсылается запрос создания объекта. Сервер запускает суррогатный процесс dllhost.exe (возможно какой-то другой, точно не знаю, но пусть будет как-то так) и передаёт ему как-то (например, в командной строке) GUID объекта и информацию о клиенте. Суррогатный процесс создаёт нужный COM-объект локально в себя (получает интерфейсный указатель), создаёт некую обвязку для удалённой работы с клиентом.

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

Это моё предположение. Если у вас другое представление о работе удалённых COM-ов, то можете попытаться объяснить как AddRef помешает выгрузке процесса.

Вернуться к обсуждению:
Что делает CoLockObjectExternal? C/C++

0