Что делает CoLockObjectExternal?

На MSDN описание совершенно непонятное. А Don Box вообще описывает это совершенно по-другому(и тоже непонятно).

Опираясь на описание из MSDN, я не понимаю, чем это отличается от AddRef.
А уж тем более, как эта функция может каким-то волшебным образом "залочить" объект.

Добавлено через 1 час 14 минут
Если используете у себя эту функцию, прошу поделиться, для чего используете.

Очень желаю понять назначение этой функции.

Надеюсь гуру откликнутся.

0

Сообщение от Хрисипп Речь же идет о том, чтобы заменить вызов CoLockObjectExternal на AddRef, т.е. на сервере. CoLockObjectExternal можно же вызвать только на сервере(где объект был создан/обитает).

А у тебя он не на сервере разве вызывается, в методе объекта?

0

Сообщение от oleg-m1973 А у тебя он не на сервере разве вызывается, в методе объекта?

Верно, на сервере, в методе. Лочим, когда мы не хотим закрывать сервер, разлочиваем -- когда считаем, что можно закрывать.

0

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

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

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

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

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

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

0

Сообщение от Ygg Он просто завершится и выгрузит ваш объект из памяти, как обычную утечку памяти.

Приведу несколько цитат из ранее упомянутой книги

In general, a server process controls its own lifetime and can elect to shut down at any time it chooses.

First, it is the job of the server process to initiate its own shutdown proactively.

Instead, the server process must explicitly initiate its own shut down when appropriate.

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

Но эти цитаты, конечно, не аргумент. Надо понять весь процесс того, как все это дело происходит. И уже аргументировать по конкретике.

0