Несколько вопросов по СОМ

← →
Serginio (2003-08-04 16:03) [0]

На досуге прочитал код SConnect,ScktMain и возникло несколько вопросов по организации маршалинга в СОМ.
Суть прокси и стабов понятна (Аналог TDataDispatch,TTransportThread и TSocketDispatcher,TSocketDispatcherThread). Единственно, что TSocketDispatcherThread нет привязки объекта к месту создания. Не знаю почему многие говорят о невозможности поддержки обратных вызовов в TSocketConnection, на самом деле она реализована. По сути в Delphi реализован вызов ciMultiInstance,tmApartment.

Причем при вызове метода происходи PostThreadMessage, а внутри TTransportThread организована цикл сообщений с выборкой через PeekMessage(msg, 0, 0, 0, PM_REMOVE).

Вот сдесь первый вопрос какие сообщения просматриваются данным методом, и чему должен быть равен msg.hwnd для данного потока (поидее 0 или ThreadID, но не должны попадать сообщения другим потокам).

По идее СОМ создает свой прокси на основании ItypeInfo или других интерфейсов поддерживающих сбор информации из библиотеки типов или через IDispatch как TDataDispatch. Причем может быть сделана полная виртуальная копия объекта подменяющая его методы на основании VMT и данных о параметрах.
В зависимости от расположении объекта применяется RCP или через механизм сообщений.

Вот здесь второй вопрос.
Каков механизм создания и работы апартаментов как на сервере так и на клиенте. (с STA все просто)????

Третий вопрос. Можно ли узнать как в Net реальный это объект или прокси.

Заранее благодарен на тыкание носом.

← →
Набережных С. (2003-08-04 18:58) [1]

>чему должен быть равен msg.hwnd для данного потока

Нулю. ThreadID указывается при вызове PostThreadMessage.

>Каков механизм создания и работы апартаментов как на сервере так и на клиенте. (с STA все просто)????

Не слабо:) Страниц на 10 потянет, а то и больше. Очень схематично: Во-первых, создание маршаллера через IDispatch и/или ITypeInfo не единственный возможный способ. Существует так-же стандартный маршалинг, когда прокси и стаб представляют собой COM-объекты, реализующие специальные интерфейсы. Еще возможен маршаллинг путем реализации объектом интерфейса IMarshal.
Апартамент инициируется при первом вызове CoInitializeEx. Если содается MTA, то все потоки, которые в дальнейшем будут вызывать CoInitializeEx с указанием такой-же модели, будут включены в этот же апартамент. Для передачи вызова в этот апартамент используется один из протоколов RPC. Какой именно, не документированно и может изменяться. Можно сделать некоторые предроложения, но вряд ли это имеет смысл. В случае MTA инициируется кэш потоков RPC, из него выделяется один поток, который начинает ждать внешние вызовы. Когда такой вызов приходит, этот поток его обрабатывает, а из кэша выделяется новый поток, который ждет следующего вызова. Обработав вызов, первый поток возвращается в кэш и через некоторое время может быть уничтожен. В случае STA есть свои сложности и тонкости, связанные с использованием очереди сообщений и обеспечением реентерабельности, но раз тебе это известно, то я на них останавливаться не буду.

>Можно ли узнать как в Net реальный это объект или прокси

Например, можно запросить интерфейс IClientSecurity. В случае удачи - это прокси.

← →
Serginio (2003-08-04 19:39) [2]

Большое Спасибо.
А можно чучь чуть поподробнее
"В случае STA есть свои сложности и тонкости, связанные с использованием очереди сообщений и обеспечением реентерабельности"

← →
Набережных С. (2003-08-04 20:48) [3]

В STA может выполняться только один, создавший его, поток. Следовательно, RPC не может использовать свои потоки для передачи вызова объекту в нем. Вместо этого при инициализации апартамента в нем создается специальное скрытое окно с довольно характерным именем класса. ORPC перенаправляет вызов путем отправки через PostMessage сообщения этому окну. Его оконная функция умеет извлекать из сообщения указатель на соответствующую заглушку и переправлять вызов ей. Отсюда вытекает необходимость организации в потоке цикла выборки и диспетчирезации сообщений. Т.к. вызов должен выполняться синхронно, то ORPC должен обеспечить ожидания окончания обработки. Но, с друго стороны, необходимо обеспечить повторную входимость потока, в том числе и для поддержки обратных вызовов. Для этого ORPC во время ожидания ответа организует внутренний цикл выборки сообщений. По умолчанию, в этом цикле обрабатываются все поступившие сообщения. Такое поведение не всегда приемлемо, часто требуется обработку некоторых вызовов отложить. Для этого предусмотрен механизм фильтрации. Ты создаешь объект, реализующий интерфейс IMessageFilter и регистрируешь его функцией CoRegisterMessageFilter. В результате получаешь возможность управлять выборкой поступающих вызовов.

Все это далеко не полно. Кроме того, многие нюансы я уже наверняка забыл из-за редкой надобности. В MSDN это описано гораздо полнее и подробнее. Очень советую почитать.

← →
Serginio (2003-08-04 21:07) [4]

Еще раз Огромное Спасибо. Скопирую ветку. Хотя надобности и нет, но интересны приемы которые в дальнейшем можно использовать в своей практике. Изучать буду обязательно, но только уже в как это организовано в Net. К сожалению у меня не очень хорошие отношения с Английским.

Несколько вопросов по СОМ Найти похожие ветки