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

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 ) СОМ.