О какой выгоде говорит статья MSDN о CoRevokeClassObject?

Question

В статье MSDN о CoRevokeGetClassObject () говорится, что при вызове COM-сервером объект класса, на который ссылаются клиенты, не освобождается. Затем приходит следующее:

Если другие клиенты по-прежнему имеют указатели на объект класса и вызвали увеличение счетчика ссылок при вызове IUnknown :: AddRef, счетчик ссылок не будет> нуля. Когда это происходит, приложения могут выиграть, если последующие вызовы (с очевидными> исключениями IUnknown :: AddRef и IUnknown :: Release) к объекту класса завершатся неудачей.

Что подразумевается под "приложениями, которые могут принести пользу"? Объект класса не освобождается, но запросы на создание не выполняются. Звучит разумно, но где выгода?

Answer 1

Да, это довольно странный поворот слов ...

Я думаю, что они пытаются сказать, что клиенты могут оказаться в сложной ситуации, если они создадут объекты с сервера, который только что назвал CoRevokeClassObjects, потому что, скорее всего, он очень скоро исчезнет (CoRevokeClassObjects обычно вызывается, когда сервер выключен.)

Таким образом, если вызовы активации (IClassFactory::CreateInstance) не завершаются неудачно, клиент получит указатель интерфейса обратно, и как только он вызовет метод для него, он получит ошибку от уровня RPC, что сервер ушел.

Полагаю, это в некоторой степени полезно: -)

Тем не менее, я не уверен, как обнаружить случай, когда IUnknown::Release вызывается через CoRevokeClassObjects против какого-либо другого клиента, но я полагаю, что код, отменяющий фабрики, может установить некоторое глобальное состояние или состояние для каждой фабрики, они могут проверить, прежде чем пропустить запросы на создание.