Сущность технологии СОМ. Библиотека программиста
Шрифт:
ICallback *pcb = 0;
HRESULT hr = CoCreateInstance(CLSID_Callback, 0, CLSCTX_ALL,
IID_ICallback, (void**)&pcb);
assert(SUCCEEDED(hr));
// callback object lives in this apt.
// объект обратного вызова живет в этом апартаменте
I0bject "po = 0;
hr = CoCreateInstance(CLSID_Object, 0, CLSCTX_REMOTE_SERVER,
IID_Iobject, (void **)&po);
assert(SUCCEEDED(hr));
// object lives in different apt.
// объект живет в другом апартаменте
// make a call to remote object, marshaling a reference to
// the callback object as an [in] parameter
// делаем вызов удаленного объекта, маршалируя ссылку
// на объект обратного вызова как на [in]-параметр
hr = po->UseCallback(pcb);
// clean up resources
//
pcb->Release;
pco->Release;
На рис. 5.6 показано, что если апартамент вызывающего объекта не поддерживает реентерабельность, то следующая реализация метода UseCallback вызовет взаимоблокировку:
STDMETHODIMP Object::UseCallback(ICallback *pcb) {
HRESULT hr = pcb->GetBackToCallersApartment;
assert(SUCCEEDED(hr));
return S_OK;
Напомним, что когда [in]–параметр передается через метод заместителя UseCallback, то заместитель вызывает CoMarshalInterface для маршалинга интерфейсного указателя ICallback. Поскольку указатель ссылается на объект, находящийся в апартаменте вызывающего объекта, то этот апартамент становится экспортером объектов и поэтому любые межапартаментные вызовы объекта должны обслуживаться в апартаменте вызывающего объекта. Когда заглушка интерфейса IObject демаршалирует интерфейс ICallback, она создает заместитель для передачи его реализации метода UseCallback. Этот заместитель представляет объект при промежуточном соединении с объектом обратного вызова, которое продолжается на протяжении всего времени вызова. Время существования этого заместителя/соединения может превысить время вызова, если реализация метода просто вызовет AddRef на заместитель [2] :
2 По недоразумению широко распространено мнение, что для обеспечения двухсторонней связи или обратных вызовов требуются точки стыковки (Connection Points). Как описывается в главе 7, точки стыковки необходимы только для поддержки программ обработки событий в Visual Basic и для сред подготовки сценариев.
STDMETHODIMP Object::UseCallback(ICallback *pcb) {
if (!pcb) return E_INVALIDARG;
// hold onto proxy for later use
// сохраняем в заместителе для дальнейшего использования
(m_pcbMyCaller = pcb)->AddRef;
return S_OK; }
Обратное соединение с апартаментом клиента будет длиться до тех пор, пока заместитель не будет освобожден объектом. Поскольку все апартаменты СОМ могут получать ORPC-запросы, объект может послать обратный вызов в апартамент клиента в любое время.
Реентерабельность реализуется для каждого типа апартаментов по-разному. Наиболее проста реализация в случае МТА, так как МТА-апартаменты не гарантируют параллелизма и не указывают, какой поток будет обслуживать заданный вызов метода. Повторный вызов может прийти в то время, когда МТА-поток заблокирован в канале в ожидании ORPC-ответа. Тогда RPC-поток, получающий повторный запрос, просто входит в МТА и обслуживает вызов своими ресурсами. Тот факт, что другой поток апартамента заблокирован и ожидании ORPC-ответа, не влияет на диспетчеризацию вызова. В случае реализации RTA – когда поток, выполняющийся в RTA, делает межапартаментный вызов посредством заместителя, – канал уступает контроль над апартаментом, снимая блокировку всего RTA и разрешая тем самым обработку поступивших вызовов. И снова, но причине отсутствия привязки объектов к потокам в RTA, RPC-поток, получающий ORPC-запрос, может просто войти в апартамент RTA
и обслужить вызов сразу после блокирования всего RTA.Реализация реентерабельности для апартаментов STA более сложна. Поскольку STA-объекты обладают привязкой к потоку, то когда поток делает межапартаментный вызов из STA, СОМ не может разрешить потоку сделать блокирующий вызов, который предотвратил бы обработку входящих ORPC-запросов. Когда поток вызывающего объекта входит в метод канала SendReceive , чтобы послать ORPC-запрос и получить ORPC-ответ, этот канал захватывает поток вызывающего объекта и помещает его во внутренний оконный MSG– цикл. Это аналогично тому, что происходит при создании потоком модальных диалоговых окон. В обоих случаях поток вызывающего объекта вынужден обслуживать определенные классы оконных сообщений во время выполнения этой операции. В случае модальных диалоговых окон поток должен обслуживать основные оконные сообщения, чтобы разморозить основной пользовательский интерфейс. В случае межапартаментного вызова метода в СОМ поток должен обслуживать не только обычные оконные сообщения пользовательского интерфейса, но и оконные сообщения, относящиеся к поступающим ORPC-запросам. По умолчанию канал будет разрешать обслуживание всех поступающих ORPC-вызовов, пока клиентский поток ожидает ORPC-ответа. Такой режим можно настроить с помощью установки в потоке специального фильтра сообщений.
Фильтры сообщений являются уникальными для STA. Фильтр сообщений – это объект СОМ для каждого STA, который используется для решения вопроса, организовать диспетчеризацию поступающих ORPC-запросов или нет. Кроме того, фильтры сообщений используются для размещения задержанных сообщений пользовательского интерфейса, пока поток STA ожидает ORPC-ответа внутри канала. Фильтры сообщений выставляют интерфейс IMessageFilter:
[ uuid(00000016-0000-0000-C000-000000000046),local, object ]
interface IMessageFilter : IUnknown {
typedef struct tagINTERFACEINFO {
IUnknown *pUnk;
// 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