Сущность технологии СОМ. Библиотека программиста

// which object?

// чей объект?

IID iid;

// which interface?

// чей интерфейс?

WORD wMethod;

// which method?

// чей метод?

} INTERFACEINFO;

// called when an incoming ORPC request arrives in an STA

// вызывается, когда входящий ORPC-запрос поступает в STA

DWORD HandleInComingCall(

[in] DWORD dwCallType,

[in] HTA5K dwThreadIdCaller,

[in] DWORD dwTickCount,

[in] INTERFACEINFO *pInterfaceInfo

);

// called when another STA rejects or postpones an ORPC request

// вызывается, когда другой STA отклоняет или откладывает ORPC-запрос

DWORD RetryRejectedCall(

[in] HTASK dwThreadIdCallee,

[in] DWORD dwTickCount,

[in] DWORD dwRejectType

);

// called when a non-COM MSG arrives while the thread is

// awaiting an ORPC response

// вызывается, когда поступает не СОМ'овское MSG, пока

// поток ожидает ORPC-ответа

DWORD MessagePending(

[in] HTASK dwThreadIdCallee,

[in] DWORD dwTickCount,

[in] DWORD dwPendingType

); }

Для установки специального фильтра сообщений в СОМ существует API-функция CoRegisterMessageFilter:

HRESULT CoRegisterMessageFilter([in] IMessageFilter *pmfNew, [out] IMessageFilter **ppmfOld);

CoRegisterMessageFilter связывает указанный фильтр сообщений с текущим STA. Предыдущий фильтр сообщений возвращается для того, чтобы вызывающий объект мог восстановить его в дальнейшем.

Когда бы входящий ORPC-запрос ни пришел в STA-поток, вызывается метод фильтра сообщений HandleIncomingCall, который дает апартаменту возможность принять, отклонить или отложить вызов. HandleIncomingCall используется как реентерабельными, так и нереентерабельными вызовами. Параметр dwCallType показывает, какой тип вызова был получен:

typedef enum tagCALLTYPE {

CALLTYPE_TOPLEVEL,

// STA not in outbound call

// STA не в исходящем вызове

CALLTYPE_NESTED,

// callback on behalf of outbound call

// обратный вызов от имени исходящего вызова

CALLTYPE_ASYNC,

// asynchronous call

// асинхронный вызов

CALLTYPE_TOPLEVEL_CALLPENDING,

// new call while waiting

// новый вызов во время ожидания

CALLTYPE_ASYNC_CALLPENDING

// async call while waiting

// асинхронный вызов во время ожидания

} CALLTYPE;

Вложенный (реентерабельный) вызов и незаконченный (нереентерабельный) вызов верхнего уровня происходят, пока поток ожидает ORPC-ответа в канале. Вызовы верхнего уровня происходят в тех случаях, когда в апартаменте нет активных вызовом.

В СОМ определено перечисление, которое должна возвратить реализация HandleIncomingCall, чтобы указать, что произошло с вызовом:

typedef enum tagSERVERCALL {

SERVERCALL_ISHANDLED,

// accept call and forward to stub

// принимаем вызов и направляем его заглушке

SERVERCALL_REJECTED,

// tell caller that call is rejected

// сообщаем вызывающему объекту, что вызов отклонен

SERVERCALL RETRYLATER

// tell caller that call is postponed

// сообщаем вызывающему объекту, что вызов отложен

} SERVERCALL;

Если функция HandleIncomingCall фильтра сообщений возвращает SERVERCALL_ISHANDLED, то вызов будет направлен в интерфейсную заглушку для демаршалинга. Фильтр сообщений, принятый по умолчанию, всегда возвращает SERVERCALL_ISHANDLED. Если HandleIncomingCall возвращает SERVERCALL_REJECTED или SERVERCALL_RETRYLATER, то фильтр сообщений вызывающего объекта будет информирован о положении вызова и ORPC-запрос будет отклонен.

Когда фильтр сообщений отвергает или откладывает вызов, то фильтр сообщений вызывающего объекта информируется об этом с помощью метода RetryRejectedCall. Этот вызов происходит в контексте апартамента вызывающего объекта, и реализация метода RetryRejectedCall фильтра сообщений может решать, повторять ли отложенный вызов. Параметр dwRejectType указывает, был ли вызов отклонен или отложен. Реализация канала вызывающего объекта будет решать, какое действие предпринять, в зависимости от значения, возвращенного RetryRejectedCall. Если RetryRejectedCall возвращает –1, то канал предположит, что повторных попыток не требуется, и немедленно заставит заместитель возвратить HRESULT, равный RPC_E_CALL_REJECTED. По умолчанию фильтр сообщений всегда возвращает –1. Любое другое значение, возвращаемое методом RetryRejectedCall, интерпретируется как число миллисекунд, через которое следует повторить вызов. Поскольку это согласование осуществляется внутри канала, то не требуется повторного ORPC-запроса со стороны заместителя. В сущности, интерфейсные маршалеры не имеют ни малейшего понятия о процессах в фильтре сообщений.

Когда размещенный в STA поток блокирован в канале в ожидании ORPC-ответа, то не связанные с СОМ оконные сообщения могут поступать в MSG -очередь потока. Когда это происходит, то фильтр сообщений STA уведомляется об этом посредством метода MessagePending. Фильтр сообщений, принятый по умолчанию, разрешает диспетчеризацию некоторых оконных сообщений, чтобы предотвратить замораживание всей оконной системы. Тем не менее, действия ввода (например, щелчки мышью, нажатие клавиш) не учитываются, чтобы конечный пользователь не начал новое взаимодействие с системой. Как уже отмечалось ранее, фильтры сообщений существуют только в апартаментах STA и не поддерживаются в RTA или МТА. Фильтры сообщений лишь обеспечивают лучшую интеграцию СОМ с потоками, обрабатывающими события от пользовательского интерфейса. Из этого следует, что все эти потоки должны выполняться в однопотоковых апартаментах. Большинство потоков, обрабатывающих события от пользовательского интерфейса, захотят установить специальный фильтр сообщений, чтобы убедиться в том, что входящие запросы не обслуживаются, пока приложение находится в такой критической фазе, в которой реентерабельность может привести к семантическим ошибкам. Фильтры сообщений не следует применять в качестве универсального механизма для управления потоками. Реализация фильтров сообщений печально известна своей неэффективностью в тех случаях, когда вызовы отклоняются или откладываются. Это делает фильтры сообщений малоприспособленными в качестве механизма для управления потоками в высокопроизводительных приложениях.

Управление жизненным циклом и маршалинг

Ранее в этой главе обсуждались взаимоотношения между администратором заглушек и объектом. Администратор заглушек создается при первом вызове CoMarshalInterface для определенного идентифицированного объекта. Администратор заглушек хранит неосвобожденные ссылки на тот объект, который он предсиавляет, и существует до тех пор, пока остается хотя бы одна неосвобожденная внешняя ссылка на заглушку. Эти внешние ссылки обычно являются заместителями, хотя учитываются и маршалированные объектные ссылки, так как они могут представлять заместители. Когда все внешние ссылки на администратор заглушек уничтожены, он самоуничтожается и освобождает все хранящиеся в нем ссылки на текущий объект. Такое поведение по умолчанию в точности имитирует обычную внутрипроцессную семантику AddRef и Release. Многие объекты не имеют никаких специальных требований относительно жизненного цикла и целиком удовлетворяются этой схемой. Некоторые объекты предпочитают дифференцировать взаимоотношения между внешними ссылками, администратором заглушек и объектом. К счастью, СОМ предоставляет администратору заглушек на время жизненного цикла достаточно приемов работы, которые позволяют реализовывать различные стратегии. Для того чтобы понять, как организован жизненный цикл заглушки, необходимо в первую очередь исследовать алгоритм распределенной сборки мусора (garbage collection) СОМ.