Страница:
STDMETHODIMP Point::UnmarshalInterface(IStream *pStm, REFIID riid, void ** ppv)
{
*ppv = 0;
// read endian header // читаем заключительный заголовок DWORD dw; ULONG cbRead;
HRESULT hr = pStm->Read(&dw, sizeof (DWORD), &cbRead);
if (FAILED(hr) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA; bool bSwapEndian = dw == 0x009966FF;
// read m_x and m_y // читаем m_x и m_y
hr = pStm->Read(&dw, sizeof(DWORD), &cbRead);
m_x = dw; if (FAILED(hr) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA;
hr = pStm->Read(&dw, sizeof(DWORD), &cbRead);
m_y = dw; if (FAILED(hr)) || cbRead != sizeof(DWORD)) return RPC_E_INVALID_DATA;
// byte swap members if necessary
// байт переставляет свои биты, если необходимо
if (bSwapEndian) byteswapdata(&m_x, &m_y);
// return pointer to this object
// возвращаем указатель на этот объект return
this->QueryInterface(riid, ppv);
}
Отметим, что реализация MarshalInterface и UnmarshalInterface должна позаботиться о том, чтобы маршалированное состояние могло читаться на любой платформе. Это означает ручную работу по выравниванию, расстановке байтов и учету различий в размерах типов данных.
Приведенная здесь реализация UnmarshalInterface просто возвращает указатель вновь созданному специальному заместителю. Для простого объекта, маршалированного по значению, это может быть приемлемо. Однако более типичные реализации UnmarshalInterface могут захотеть найти несколько демаршалированных указателей, соответствующих одной и той же идентификационной единице СОМ, и возвратить указатель на заместитель той же единицы, чтобы установить отношение идентичности заместителя объекту. Это может не только сэкономить ресурсы, но также повысить чистоту программы.
Маршалер свободной поточной обработки (FreeThreaded Marshaler)
Если в классе установлена опция ThreadingModel="Both" , то она показывает, что экземпляры класса, а также объект класса могут безопасно находиться в любых апартаментах: STA или МТА. В то же время, согласно правилам СОМ, любой данный экземпляр будет находиться только в одном апартаменте. Если бы разработчик объекта прошел все этапы проверки того, что объект может благополучно находиться в МТА, то в этом случае объекту вообще не нужно было бы заботиться об апартаментах. Одновременный доступ к подобному объекту мог бы быть не только для нескольких потоков внутри МТА, но также от потоков вне МТА (например, от потоков, выполняемых в STA). В то же время клиенты не могут знать, что такой доступ является безопасным для отдельно взятого объекта, поэтому любое совместное использование интерфейсного указателя в нескольких апартаментах должно быть установлено с использованием явной технологии маршалинга. Это означает, что доступ к внутрипроцессному объекту будет осуществляться через ORPC-вызовы, если только вызывающий объект не выполняется в том же самом апартаменте, где был создан объект.
В отличие от клиентов, объекты знают о своих отношениях с апартаментами, о своем параллелизме и реентерабельности. Объекты, удовлетворяющиеся ORPC-запросами при доступе из нескольких апартаментов одного и того же процесса, ведут себя так по умолчанию. А объект, которого не устраивает доступ ORPC, имеет возможность обойти это путем реализации специального маршалинга. Довольно просто использовать специальный маршалинг для обхода администратора заглушек и преобразования исходного указателя на объект в маршалированную объектную ссылку. При использовании этой технологии реализация специального заместителя могла бы просто считывать исходный указатель из маршалированной объектной ссылки и передавать его вызывающему объекту в импортирующем апартаменте. Клиентские потоки по-прежнему передавали бы интерфейсный указатель через границу апартамента с помощью явного или неявного вызова CoMarshalInterface / CoUnmarshalInterface. Однако объект мог бы договориться со специальным заместителем о том, чтобы просто передать исходный указатель нужному объекту. Хотя данная технология безупречно работает для внутрипроцессного маршалинга, она, к сожалению, не приводит к успеху в случае межпроцессного маршалинга. Но, к счастью, реализация объекта может просто обратиться к стандартному маршалеру за другим контекстом маршалинга, отличным от MSHCTX_INPROC.
Поскольку только что описанное поведение является полезным для большого класса объектов, в СОМ предусмотрена агрегируемая реализация IMarshal, выполняющая в точности то, что было описано. Эта реализация называется маршалером свободной поточной обработки (FreeThreaded Marshaler – FTM) и может быть осуществлена с помощью вызова API-функции CoCreateFreeThreadedMarshaler:
HRESULT CoCreateFreeThreadedMarshaler( [in] IUnknown *pUnkOuter, [out] IUnknown **ppUnkInner);
Класс, который желает использовать FTM, просто агрегирует экземпляр либо во время инициализации, либо по требованию при первом запросе QueryInterface об интерфейсе IMarshal . Следующий класс заранее обрабатывает FTM во время построения.
class Point : public IPoint {
LONG m_cRef; IUnknown *m_pUnkFTM;
long m_x; long m_y; Point(void) : m_cRef(0), m_x(0), m_y(0) {
HRESULT hr = CoCreateFreeThreadedMarshaler(this,&m_pUnkFTM);
assert(SUCCEEDED(hr)) ;
}
virtual ~Point(void) { m_pUnkFTM->Release(); }
};
Соответствующая реализация QueryInterface просто запросила бы интерфейс IMarshal из FTM:
STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv)
{ if (riid == IID_IUnknown || riid == IID_IPoint)
*ppv = static_cast<IPoint*>(this);
else if (riid == IID_IMarshal) return m_pUnkFTM->QueryInterface(riid, ppv);
else return (*ppv = 0), E_NOINTERFACE;
((IUnknown* )*ppv)->AddRef();
return S_OK;
}
Поскольку используется FTM, не понадобится никаких заместителей, как бы ни маршалировались через внутрипроцессные границы апартамента ссылки на объекты Point . Это применимо к явным вызовам CoMarshalInterface / CoUnmarshalInterface, а также в случаях, когда ссылки на объекты Point передаются как параметры метода на внутрипроцессные заместители объектов, не являющихся объектами Point.
FTM занимает не менее 16 байт памяти. Поскольку многие внутрипроцессные объекты никогда не используются за пределами своего апартамента, то предварительное выделение памяти для FTM не является лучшим использованием имеющихся ресурсов. В высшей степени вероятно, что объект уже имеет некий примитив для синхронизации потоков. В таком случае FTM может быть отложенно агрегирован (lazy-aggregated) при первом же запросе QueryInterface о IMarshal. Для того чтобы добиться этого, рассмотрим такое определение класса:
class LazyPoint : public IPoint {
LONG m_cRef; IUnknown *m_pUnkFTM;
long m_x;
long m_y;
LazyPoint (void) : m_cRef (0) .m_pUnkFTM(0),m_x(0), m_y(0) {}
virtual ~LazyPoint(void) {
if (m_pUnkFTM) m_pUnkFTM->Release();
}
void Lock(void);
// acquire object-specific lock
// запрашиваем блокировку, специфическую для объектов
void Unlock(void);
// release object-specific lock
// освобождаем блокировку, специфическую для объектов
:
:
:
};
Основываясь на таком определении класса, следующая реализация QueryInterface осуществит корректное агрегирование FTM по требованию:
STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv) {
if (riid == IID_IUnknown || riid == IID_IPoint)
*ppv = static_cast<IPoint*>(this);
else if (riid == IID_IMarshal) {
this->Lock();
HRESULT hr = E_NOINTERFACE;
*ppv = 0;
if (m_pUnkFTM == 0)
// acquire FTM first time through
// получаем первый FTM
CoCreateFreeThreadedMarshaler(this, &m_pUnkFTM);
if (m_pUnkFTM != 0)
// by here, FTM is acquired
// здесь получен FTM
hr = m_pUnkFTM->QueryInterface(riid, ppv);
this->Unlock();
return hr;
} else return (*ppv = 0), E_NOINTERFACE;
((IUnknown *)*ppv)->AddRef(); return S_OK; }
Недостатком данного подхода является то, что все запросы QueryInterface на IMarshal будут сериализованы (преобразованы в последовательную форму); тем не менее, если IMarshal вообще не будет запрошен, то будет запрошено меньше ресурсов.
Теперь, когда мы убедились в относительной простоте использования FTM, интересно обсудить случаи, в которых FTM не годится. Конечно, те объекты, которые могут существовать только в однопотоковых апартаментах, не должны использовать FTM, так как маловероятно, что они будут ожидать одновременного обращения к ним. В то же время объекты, способные работать в апартаментах МТА, отнюдь не обязаны использовать FTM. Рассмотрим следующий класс, который использует для выполнения своих операций другие СОМ-объекты:
class Rect : public IRect { LONG m_cRef; IPoint *m_pPtTopLeft; IPoint *m_pPtBottomRight; Rect(void) : m_cRef(0) {
HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**) &m_pPtTopLeft);
assert(SUCCEEDED (hr)); hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&m_pPtBottomRight);
assert (SUCCEEDED(hr));
}
;
;
;
}
Пусть класс Rect является внутрипроцессным и помечен как ThreadingModel = «Both». Разработчик данного Rect -объекта всегда будет выполняться в апартаменте потока, вызывающего CoCreateInstance (CLSID_Rect). Это означает, что два вызова CoCreateInstance (CLSID_Point) будут также выполняться в апартаменте клиента. Правила же СОМ гласят, что элементы данных m_pPtTopLeft и m_pPtBottomRight могут быть доступны только из того апартамента, который выполняет вызовы CoCreateInstance.
Похоже на то, что по меньшей мере один из методов Rect использует в своей работе два интерфейсных указателя в качестве элементов данных:
STDMETHODIMP Rect::get_Area(long *pn) {
long top, left, bottom, right;
HRESULT hr = m_pPtTopLeft->GetCoords(&left, &top);
assert(SUCCEEDED(hr));
hr = m_pPtBottomRight->GetCoords(&right, &bottom);
assert (SUCCEEDED (hr));
*pn = (right – left) * (bottom – top);
return S_OK;
}
Если бы класс Rect должен был использовать FTM, тогда можно было бы вызывать этот метод из апартаментов, отличных от того апартамента, который осуществлял начальные вызовы CoCreateInstance. К сожалению, это заставило бы метод get_Area нарушить правила СОМ, поскольку два элемента данных – интерфейсные указатели – являются легальными только в исходном апартаменте. Если бы класс Point также использовал FTM, то формально это не было бы проблемой. Тем не менее, в общем случае клиенты (такие, так класс Rect), не должны делать допущений относительно этой специфической исключительно для реализаций детали. Фактически, если объекты Point не используют FTM и окажутся созданными в другом апартаменте из-за несовместимости с ThreadingModel, то в этом случае объект Rect содержал бы указатели на заместители. Известно, что заместители четко следуют правилам СОМ и послушно возвращают RPC_E_WRONG_THREAD в тех случаях, когда к ним обращаются из недопустимого апартамента.
Это оставляет разработчику Rect выбор между двумя возможностями. Одна из них – не использовать FTM и просто принять к сведению, что когда клиенты передают объектные ссылки Rect между апартаментами, то для обращения к экземплярам класса Rect будет использоваться ORPC. Это действительно является простейшим решением, так как оно не добавляет никакого дополнительного кода и будет работать, не требуя умственных усилий. Другая возможность – не содержать исходные интерфейсные указатели как элементы данных, а вместо этого держать в качестве элементов данных некую маршалированную форму интерфейсного указателя. Именно для этого и предназначена глобальная интерфейсная таблица (Global Interface Table – GIT). Для реализации данного подхода в классе Rect следовало бы иметь в качестве элементов данных не исходные интерфейсные указатели, а «закладку» (cookies) DWORD:
class SafeRect : public IRect {
LONG m_cRef;
// СОМ reference count
// счетчик ссылок СОМ IUnknown *m_pUnkFTM;
// cache for FTM lazy aggregate
// кэш для отложенного агрегирования FTM
DWORD m_dwTopLeft;
// GIT cookie for top/left
// закладка GIT для верхнего/левого
DWORD m_dwBottomRight;
// GIT cookie for bottom/right
// закладка GIT для нижнего/правого
Разработчик по-прежнему создает два экземпляра Point, но вместо хранения исходных указателей регистрирует интерфейсные указатели с помощью глобальной таблицы GIT:
SafeRect::SafeRect(void) : m_cRef(0), m_pUnkFTM(0) {
// assume ptr to GIT is initialized elsewhere
// допустим, что указатель на GIT инициализирован
// где-нибудь в другом месте
extern IGIobalInterfaceTable *g_pGIT;
assert(g_pGIT != 0);
IPoint *pPoint = 0;
// create instance of class Point
// создаем экземпляр класса Point HRESULT
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert (SUCCEEDED (hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwTopLeft);
assert(SUCCEEDED(hr));
pPoint->Release();
// reference is now held in GIT
// ссылка теперь содержится в GIT
// create instance of class Point
// создаем экземпляр класса Point
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert(SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwBottomRight);
assert(SUCCEEDED(hr)); pPoint->Release();
// reference is now held in GIT
// ссылка теперь содержится в GIT
}
Отметим, что все то время, пока интерфейсный указатель зарегистрирован в GIT, пользователь интерфейсного указателя не должен хранить никаких дополнительных ссылок.
Поскольку класс был преобразован для использования GIT вместо исходных интерфейсных указателей, он должен демаршалировать новый заместитель в каждом вызове метода, которому требуется доступ к зарегистрированным интерфейсам:
STDMETHODIMP SafeRect::get_Area(long *pn) {
extern IGlobalInterfaceTable *g_pGIT; assert(g_pGIT != 0);
// unmarshal the two interface pointers from the GIT
// демаршалируем дВа интерфейсных указателя из GIT
IPoint *ptl = 0, *pbr = 0;
HRESULT hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtTopLeft, IID_Ipoint, (void**)&ptl);
assert (SUCCEEDED(hr));
hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtBottomRight, IID_Ipoint, (void**)&pbr);
// use temp ptrs to implement method
// дпя реализации метода используем временные указатели
long top, left, bottom, right;
hr = ptl->GetCoords(&left, &top);
assert (SUCCEEDED(hr));
hr = pbr->GetCoords(&right, &bottom);
assert (SUCCEEDED (hr));
*pn = (right – left) * (bottom – top);
// release temp ptrs. // освобождаем временные указатели
ptl->Release();
pbr->Release();
return S_OK;
}
Поскольку реализация SafeRect использует FTM, то нецелесообразно пытаться сохранить немаршалированные интерфейсные указатели между вызовами метода, так как неизвестно, произойдет ли следующий вызов метода в том же самом апартаменте.
Все зарегистрированные интерфейсные указатели будут храниться в таблице GIT до тех пор, пока они не будут явно удалены нз GIT. Это означает, что класс SafeRect должен явно аннулировать элементы GIT для двух своих элементов данных:
SafeRect::~SafeRect(void) {
extern IGlobalInterfaceTable *g_pGIT;
assert(g_pGIT != 0);
HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwTopLeft);
assert(SUCCEEDED(hr));
hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwBottomRight);
assert(SUCCEEDED(hr));
}
Удаление интерфейсного указателя из GIT освобождает все хранящиеся ссылки на объект.
Отметим, что совместное использование GIT и FTM влечет за собой очень много обращений к GIT, которые будут сделаны для создания временных интерфейсных указателей, необходимых для использования в каждом отдельном методе. Хотя GIT оптимизирована именно для поддержки такой схемы использования, код остается однообразным. Следующий простой класс C++ скрывает использование «закладки» GIT за удобным интерфейсом, обеспечивающим безопасность типа:
template <class Itf, const IID* piid> class GlobalInterfacePointer {
DWORD m_dwCookie;
// the GIT cookie
// «закладка» GIT
// prevent misuse
// предотвращаем неправильное использование
GlobalInterfacePointer(const GlobalInterfacePointer&);
void operator =(const GlobalInterfacePointer&);
public:
// start as invalid cookie
// начинаем как неправильная «закладка»
GlobalInterfacePointer(void) : m_dwCookie(0) { }
// start with auto-globalized local pointer
// начинаем с автоматически глобализованным локальным указателем
GlobalInterfacePointer(Itf *pItf, HRESULT& hr) : m_dwCookie(0)
{ hr = Globalize(pItf); }
// auto-unglobalize
// осуществляем автоматическую деглобапизацию
~GlobalInterfacePointer(void) { if(m_dwСооkiе) Unglobalize() ; }
// register an interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
HRESULT Globalize(Itf *pItf) { assert (g_pGIT != 0 && m_dwCookie == 0);
return g_pGIT->RegisterInterfaceInGlobal(pItf, * piid, &m_dwCookie);
}
// revoke an interface pointer in GIT
// аннулируем интерфейсный указатель в GIT
HRESULT Unglobalize(void) {
assert(g_pGIT != 0 && m_dwCookie != 0);
HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwCookie);
m_dwCookie = 0;
return hr;
}
// get а local interface pointer from GIT
// получаем локальный интерфейсный указатель из GIT
HRESULT Localize(Itf **ppItf) const {
assert(g_pGIT != 0 && m_dwCookie != 0);
return g_pGIT->GetInteгfaceFromGlobal(m_dwCookie, *piid, (void**)ppItf);
}
// convenience methods
// методы для удобства
bool IsOK(void) const { return m_dwCookie != 0; }
DWORD GetCookie(void) const { return m_dwCookie; }
};
#define GIP(Itf) GlobalInterfacePointer<Itf, &IID_##Itf>
Имея данное определение класса и макрос, класс SafeRect теперь вместо исходных DWORD сохраняет GlobalInterfacePointers:
class SafeRect : public IRect {
LONG m_cRef:
// СОM reference count
// счетчик ссылок СОМ
IUnknown *m_pUnkFTM;
// cache for FTM lazy aggregate
// кэш дпя отложенного агрегирования FTM
GIP(IPoint) m_gipTopLeft;
// GIT cookie – top/left
// «закладка» GIT для верхнего/левого элемента
GIP(IPoint) m_gipBottomRight;
// GIT cookie – bottom/right
// «закладка» GIT для нижнего/правого элемента
:
:
:
}
Для инициализации элемента GlobalInterfacePointer разработчик (который выполняется в апартаменте объекта) просто регистрирует обрабатываемые указатели, вызывая метод Globalize на каждый GlobalInterfacePointer:
SafeRect::SafeRect(void) : m_cRef (0), m_pUnkFTM(0) {
IPoint *pPoint = 0;
// create instance of class Point
// создаем экземпляр класса Point
HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert (SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = m_gipTopLeft.Globalize(pPoint);
assert (SUCCEEDED(hr));
pPoint->Release();
// reference is now held in GIT
// теперь ссыпка хранится в GIT
// create instance of class Point
// создаем экземпляр класса Point
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Iроint, (void**) &рРоint);
assert(SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = m_gipBottomRight.Globalize(pPoint);
assert (SUCCEEDED (hr));
pPoint->Release();
// reference is now held in GIT
// теперь ссылка хранится в GIT
}
Те методы, которым нужен доступ к глобализованным указателям, могут импортировать локальную копию посредством метода Localize из GlobalInterfaсePointer:
STDMETHODIMP SafeRect::get_Top(long *pVal) {
IPoint *pPoint = 0;
// local imported pointer
// локальный импортированный указатель
HRESULT hr = m_gipTopLeft.Localize(&pPoint);
if (SUCCEEDED(hr)){
long x;
hr = pPoint->get_Coords(&x, pVal);
pPoint->Release(); }
return hr;
}
Отметим, что в силу применения маршалера свободной поточной обработки (FreeThreaded Marshaler) исходный интерфейсный указатель не может быть кэширован, а должен импортироваться при каждом вызове метода, чтобы предотвратить попытку доступа из неверного апартамента.
Предыдущий фрагмент кода может быть автоматизирован еще больше. Поскольку большинство вызовов методов в классе GlobalInterfacePointer должны будут локализовать временный указатель в самом вызове метода, то приводимый ниже класс автоматизирует импорт временного указателя и его последующее освобождение, что очень напоминает интеллектуальный указатель (smart pointer):
template <class Itf, const IID* piid> class LocalInterfacePointer {
Itf *m_pItf;
// temp imported pointer
// временный импортированный указатель
// prevent misuse
// предотвращаем неверное использование
LocalInterfacePointer(const LocalInterfacePointer&);
operator = (const LocalInterfacePointer&);
public:
LocalInterfacePointer(const GlobalInterfacePointer<Itf, piid>& rhs, HRESULT& hr) { hr = rhs.Loca1ize(&m_pItf) ; }
LocalInterfacePointer(DWORD dwCookie, HRESULT& hr) { assert(g_pGIT != 0);
hr = g_pGIT->GetInterfaceFromGlobal(dwCookie, *piid, (void**)&m_pItf); }
~LocalInterfacePointer(void) { if (m_pItf) m_pItf->Release(); }
class SafeItf : public Itf { STDMETHOD_(ULONG, AddRef) (void) = 0;
// hide
// скрытый STDMETHOD_(ULONG, Release)(void) = 0;
// hide
// скрытый
};
SafeItf *GetInterface(void) const { return (SafeItf*) m_pItf; }
SafeItf *operator ->(void) const { assert(m_pItf != 0);
return GetInterface();
}
};
#def1ne LIP(Itf) LocalInterfacePointer<Itf, &IID_##Itf>
С получением этого второго класса C++ обработка импортированных указателей становится намного проще:
STDMETHODIMP SafeRect::get_Area(long *pn) {
long top, left, bottom, right;
HRESULT hr, hr2;
// import pointers
// импортируем указатели
LIP(IPoint) lipTopLeft(m_gipTopLeft, hr);
LIP(IPoint) lipBottomRight(m_gipBottomRight, hr2);
assert(SUCCEEDED(hr) && SUCCEEDED(hr2));
// use temp tocal pointers
// используем временные локальные указатели
hr = lipTopLeft->GetCoords(&left, &top);
hr2 = lipBottomRight->GetCoords(&right, &bottom);
assert(SUCCEEDED(hr) && SUCCEEDED(hr2));
*pn = (right – left) * (bottom – top); return S_OK;
// LocalInterfacePointer auto-releases temp ptrs.
// LocalInterfacePointer сам освобождает
// временные указатели
}
Макросы GIP и LIP делают совместное использование GIT и FTM намного менее громоздким. До появления GIT использование FTM в классе с интерфейсными указателями было значительно более трудным, чем теперь обеспечивает любой из кодов, приведенных в данном разделе.
В отличие от клиентов, объекты знают о своих отношениях с апартаментами, о своем параллелизме и реентерабельности. Объекты, удовлетворяющиеся ORPC-запросами при доступе из нескольких апартаментов одного и того же процесса, ведут себя так по умолчанию. А объект, которого не устраивает доступ ORPC, имеет возможность обойти это путем реализации специального маршалинга. Довольно просто использовать специальный маршалинг для обхода администратора заглушек и преобразования исходного указателя на объект в маршалированную объектную ссылку. При использовании этой технологии реализация специального заместителя могла бы просто считывать исходный указатель из маршалированной объектной ссылки и передавать его вызывающему объекту в импортирующем апартаменте. Клиентские потоки по-прежнему передавали бы интерфейсный указатель через границу апартамента с помощью явного или неявного вызова CoMarshalInterface / CoUnmarshalInterface. Однако объект мог бы договориться со специальным заместителем о том, чтобы просто передать исходный указатель нужному объекту. Хотя данная технология безупречно работает для внутрипроцессного маршалинга, она, к сожалению, не приводит к успеху в случае межпроцессного маршалинга. Но, к счастью, реализация объекта может просто обратиться к стандартному маршалеру за другим контекстом маршалинга, отличным от MSHCTX_INPROC.
Поскольку только что описанное поведение является полезным для большого класса объектов, в СОМ предусмотрена агрегируемая реализация IMarshal, выполняющая в точности то, что было описано. Эта реализация называется маршалером свободной поточной обработки (FreeThreaded Marshaler – FTM) и может быть осуществлена с помощью вызова API-функции CoCreateFreeThreadedMarshaler:
HRESULT CoCreateFreeThreadedMarshaler( [in] IUnknown *pUnkOuter, [out] IUnknown **ppUnkInner);
Класс, который желает использовать FTM, просто агрегирует экземпляр либо во время инициализации, либо по требованию при первом запросе QueryInterface об интерфейсе IMarshal . Следующий класс заранее обрабатывает FTM во время построения.
class Point : public IPoint {
LONG m_cRef; IUnknown *m_pUnkFTM;
long m_x; long m_y; Point(void) : m_cRef(0), m_x(0), m_y(0) {
HRESULT hr = CoCreateFreeThreadedMarshaler(this,&m_pUnkFTM);
assert(SUCCEEDED(hr)) ;
}
virtual ~Point(void) { m_pUnkFTM->Release(); }
};
Соответствующая реализация QueryInterface просто запросила бы интерфейс IMarshal из FTM:
STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv)
{ if (riid == IID_IUnknown || riid == IID_IPoint)
*ppv = static_cast<IPoint*>(this);
else if (riid == IID_IMarshal) return m_pUnkFTM->QueryInterface(riid, ppv);
else return (*ppv = 0), E_NOINTERFACE;
((IUnknown* )*ppv)->AddRef();
return S_OK;
}
Поскольку используется FTM, не понадобится никаких заместителей, как бы ни маршалировались через внутрипроцессные границы апартамента ссылки на объекты Point . Это применимо к явным вызовам CoMarshalInterface / CoUnmarshalInterface, а также в случаях, когда ссылки на объекты Point передаются как параметры метода на внутрипроцессные заместители объектов, не являющихся объектами Point.
FTM занимает не менее 16 байт памяти. Поскольку многие внутрипроцессные объекты никогда не используются за пределами своего апартамента, то предварительное выделение памяти для FTM не является лучшим использованием имеющихся ресурсов. В высшей степени вероятно, что объект уже имеет некий примитив для синхронизации потоков. В таком случае FTM может быть отложенно агрегирован (lazy-aggregated) при первом же запросе QueryInterface о IMarshal. Для того чтобы добиться этого, рассмотрим такое определение класса:
class LazyPoint : public IPoint {
LONG m_cRef; IUnknown *m_pUnkFTM;
long m_x;
long m_y;
LazyPoint (void) : m_cRef (0) .m_pUnkFTM(0),m_x(0), m_y(0) {}
virtual ~LazyPoint(void) {
if (m_pUnkFTM) m_pUnkFTM->Release();
}
void Lock(void);
// acquire object-specific lock
// запрашиваем блокировку, специфическую для объектов
void Unlock(void);
// release object-specific lock
// освобождаем блокировку, специфическую для объектов
:
:
:
};
Основываясь на таком определении класса, следующая реализация QueryInterface осуществит корректное агрегирование FTM по требованию:
STDMETHODIMP Point::QueryInterface(REFIID riid, void **ppv) {
if (riid == IID_IUnknown || riid == IID_IPoint)
*ppv = static_cast<IPoint*>(this);
else if (riid == IID_IMarshal) {
this->Lock();
HRESULT hr = E_NOINTERFACE;
*ppv = 0;
if (m_pUnkFTM == 0)
// acquire FTM first time through
// получаем первый FTM
CoCreateFreeThreadedMarshaler(this, &m_pUnkFTM);
if (m_pUnkFTM != 0)
// by here, FTM is acquired
// здесь получен FTM
hr = m_pUnkFTM->QueryInterface(riid, ppv);
this->Unlock();
return hr;
} else return (*ppv = 0), E_NOINTERFACE;
((IUnknown *)*ppv)->AddRef(); return S_OK; }
Недостатком данного подхода является то, что все запросы QueryInterface на IMarshal будут сериализованы (преобразованы в последовательную форму); тем не менее, если IMarshal вообще не будет запрошен, то будет запрошено меньше ресурсов.
Теперь, когда мы убедились в относительной простоте использования FTM, интересно обсудить случаи, в которых FTM не годится. Конечно, те объекты, которые могут существовать только в однопотоковых апартаментах, не должны использовать FTM, так как маловероятно, что они будут ожидать одновременного обращения к ним. В то же время объекты, способные работать в апартаментах МТА, отнюдь не обязаны использовать FTM. Рассмотрим следующий класс, который использует для выполнения своих операций другие СОМ-объекты:
class Rect : public IRect { LONG m_cRef; IPoint *m_pPtTopLeft; IPoint *m_pPtBottomRight; Rect(void) : m_cRef(0) {
HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**) &m_pPtTopLeft);
assert(SUCCEEDED (hr)); hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&m_pPtBottomRight);
assert (SUCCEEDED(hr));
}
;
;
;
}
Пусть класс Rect является внутрипроцессным и помечен как ThreadingModel = «Both». Разработчик данного Rect -объекта всегда будет выполняться в апартаменте потока, вызывающего CoCreateInstance (CLSID_Rect). Это означает, что два вызова CoCreateInstance (CLSID_Point) будут также выполняться в апартаменте клиента. Правила же СОМ гласят, что элементы данных m_pPtTopLeft и m_pPtBottomRight могут быть доступны только из того апартамента, который выполняет вызовы CoCreateInstance.
Похоже на то, что по меньшей мере один из методов Rect использует в своей работе два интерфейсных указателя в качестве элементов данных:
STDMETHODIMP Rect::get_Area(long *pn) {
long top, left, bottom, right;
HRESULT hr = m_pPtTopLeft->GetCoords(&left, &top);
assert(SUCCEEDED(hr));
hr = m_pPtBottomRight->GetCoords(&right, &bottom);
assert (SUCCEEDED (hr));
*pn = (right – left) * (bottom – top);
return S_OK;
}
Если бы класс Rect должен был использовать FTM, тогда можно было бы вызывать этот метод из апартаментов, отличных от того апартамента, который осуществлял начальные вызовы CoCreateInstance. К сожалению, это заставило бы метод get_Area нарушить правила СОМ, поскольку два элемента данных – интерфейсные указатели – являются легальными только в исходном апартаменте. Если бы класс Point также использовал FTM, то формально это не было бы проблемой. Тем не менее, в общем случае клиенты (такие, так класс Rect), не должны делать допущений относительно этой специфической исключительно для реализаций детали. Фактически, если объекты Point не используют FTM и окажутся созданными в другом апартаменте из-за несовместимости с ThreadingModel, то в этом случае объект Rect содержал бы указатели на заместители. Известно, что заместители четко следуют правилам СОМ и послушно возвращают RPC_E_WRONG_THREAD в тех случаях, когда к ним обращаются из недопустимого апартамента.
Это оставляет разработчику Rect выбор между двумя возможностями. Одна из них – не использовать FTM и просто принять к сведению, что когда клиенты передают объектные ссылки Rect между апартаментами, то для обращения к экземплярам класса Rect будет использоваться ORPC. Это действительно является простейшим решением, так как оно не добавляет никакого дополнительного кода и будет работать, не требуя умственных усилий. Другая возможность – не содержать исходные интерфейсные указатели как элементы данных, а вместо этого держать в качестве элементов данных некую маршалированную форму интерфейсного указателя. Именно для этого и предназначена глобальная интерфейсная таблица (Global Interface Table – GIT). Для реализации данного подхода в классе Rect следовало бы иметь в качестве элементов данных не исходные интерфейсные указатели, а «закладку» (cookies) DWORD:
class SafeRect : public IRect {
LONG m_cRef;
// СОМ reference count
// счетчик ссылок СОМ IUnknown *m_pUnkFTM;
// cache for FTM lazy aggregate
// кэш для отложенного агрегирования FTM
DWORD m_dwTopLeft;
// GIT cookie for top/left
// закладка GIT для верхнего/левого
DWORD m_dwBottomRight;
// GIT cookie for bottom/right
// закладка GIT для нижнего/правого
Разработчик по-прежнему создает два экземпляра Point, но вместо хранения исходных указателей регистрирует интерфейсные указатели с помощью глобальной таблицы GIT:
SafeRect::SafeRect(void) : m_cRef(0), m_pUnkFTM(0) {
// assume ptr to GIT is initialized elsewhere
// допустим, что указатель на GIT инициализирован
// где-нибудь в другом месте
extern IGIobalInterfaceTable *g_pGIT;
assert(g_pGIT != 0);
IPoint *pPoint = 0;
// create instance of class Point
// создаем экземпляр класса Point HRESULT
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert (SUCCEEDED (hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwTopLeft);
assert(SUCCEEDED(hr));
pPoint->Release();
// reference is now held in GIT
// ссылка теперь содержится в GIT
// create instance of class Point
// создаем экземпляр класса Point
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert(SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = g_pGIT->RegisterInterfaceInGlobal(pPoint, IID_Ipoint, &m_dwBottomRight);
assert(SUCCEEDED(hr)); pPoint->Release();
// reference is now held in GIT
// ссылка теперь содержится в GIT
}
Отметим, что все то время, пока интерфейсный указатель зарегистрирован в GIT, пользователь интерфейсного указателя не должен хранить никаких дополнительных ссылок.
Поскольку класс был преобразован для использования GIT вместо исходных интерфейсных указателей, он должен демаршалировать новый заместитель в каждом вызове метода, которому требуется доступ к зарегистрированным интерфейсам:
STDMETHODIMP SafeRect::get_Area(long *pn) {
extern IGlobalInterfaceTable *g_pGIT; assert(g_pGIT != 0);
// unmarshal the two interface pointers from the GIT
// демаршалируем дВа интерфейсных указателя из GIT
IPoint *ptl = 0, *pbr = 0;
HRESULT hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtTopLeft, IID_Ipoint, (void**)&ptl);
assert (SUCCEEDED(hr));
hr = g_pGIT->GetInterfaceFromGlobal(m_dwPtBottomRight, IID_Ipoint, (void**)&pbr);
// use temp ptrs to implement method
// дпя реализации метода используем временные указатели
long top, left, bottom, right;
hr = ptl->GetCoords(&left, &top);
assert (SUCCEEDED(hr));
hr = pbr->GetCoords(&right, &bottom);
assert (SUCCEEDED (hr));
*pn = (right – left) * (bottom – top);
// release temp ptrs. // освобождаем временные указатели
ptl->Release();
pbr->Release();
return S_OK;
}
Поскольку реализация SafeRect использует FTM, то нецелесообразно пытаться сохранить немаршалированные интерфейсные указатели между вызовами метода, так как неизвестно, произойдет ли следующий вызов метода в том же самом апартаменте.
Все зарегистрированные интерфейсные указатели будут храниться в таблице GIT до тех пор, пока они не будут явно удалены нз GIT. Это означает, что класс SafeRect должен явно аннулировать элементы GIT для двух своих элементов данных:
SafeRect::~SafeRect(void) {
extern IGlobalInterfaceTable *g_pGIT;
assert(g_pGIT != 0);
HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwTopLeft);
assert(SUCCEEDED(hr));
hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwBottomRight);
assert(SUCCEEDED(hr));
}
Удаление интерфейсного указателя из GIT освобождает все хранящиеся ссылки на объект.
Отметим, что совместное использование GIT и FTM влечет за собой очень много обращений к GIT, которые будут сделаны для создания временных интерфейсных указателей, необходимых для использования в каждом отдельном методе. Хотя GIT оптимизирована именно для поддержки такой схемы использования, код остается однообразным. Следующий простой класс C++ скрывает использование «закладки» GIT за удобным интерфейсом, обеспечивающим безопасность типа:
template <class Itf, const IID* piid> class GlobalInterfacePointer {
DWORD m_dwCookie;
// the GIT cookie
// «закладка» GIT
// prevent misuse
// предотвращаем неправильное использование
GlobalInterfacePointer(const GlobalInterfacePointer&);
void operator =(const GlobalInterfacePointer&);
public:
// start as invalid cookie
// начинаем как неправильная «закладка»
GlobalInterfacePointer(void) : m_dwCookie(0) { }
// start with auto-globalized local pointer
// начинаем с автоматически глобализованным локальным указателем
GlobalInterfacePointer(Itf *pItf, HRESULT& hr) : m_dwCookie(0)
{ hr = Globalize(pItf); }
// auto-unglobalize
// осуществляем автоматическую деглобапизацию
~GlobalInterfacePointer(void) { if(m_dwСооkiе) Unglobalize() ; }
// register an interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
HRESULT Globalize(Itf *pItf) { assert (g_pGIT != 0 && m_dwCookie == 0);
return g_pGIT->RegisterInterfaceInGlobal(pItf, * piid, &m_dwCookie);
}
// revoke an interface pointer in GIT
// аннулируем интерфейсный указатель в GIT
HRESULT Unglobalize(void) {
assert(g_pGIT != 0 && m_dwCookie != 0);
HRESULT hr = g_pGIT->RevokeInterfaceFromGlobal(m_dwCookie);
m_dwCookie = 0;
return hr;
}
// get а local interface pointer from GIT
// получаем локальный интерфейсный указатель из GIT
HRESULT Localize(Itf **ppItf) const {
assert(g_pGIT != 0 && m_dwCookie != 0);
return g_pGIT->GetInteгfaceFromGlobal(m_dwCookie, *piid, (void**)ppItf);
}
// convenience methods
// методы для удобства
bool IsOK(void) const { return m_dwCookie != 0; }
DWORD GetCookie(void) const { return m_dwCookie; }
};
#define GIP(Itf) GlobalInterfacePointer<Itf, &IID_##Itf>
Имея данное определение класса и макрос, класс SafeRect теперь вместо исходных DWORD сохраняет GlobalInterfacePointers:
class SafeRect : public IRect {
LONG m_cRef:
// СОM reference count
// счетчик ссылок СОМ
IUnknown *m_pUnkFTM;
// cache for FTM lazy aggregate
// кэш дпя отложенного агрегирования FTM
GIP(IPoint) m_gipTopLeft;
// GIT cookie – top/left
// «закладка» GIT для верхнего/левого элемента
GIP(IPoint) m_gipBottomRight;
// GIT cookie – bottom/right
// «закладка» GIT для нижнего/правого элемента
:
:
:
}
Для инициализации элемента GlobalInterfacePointer разработчик (который выполняется в апартаменте объекта) просто регистрирует обрабатываемые указатели, вызывая метод Globalize на каждый GlobalInterfacePointer:
SafeRect::SafeRect(void) : m_cRef (0), m_pUnkFTM(0) {
IPoint *pPoint = 0;
// create instance of class Point
// создаем экземпляр класса Point
HRESULT hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Ipoint, (void**)&pPoint);
assert (SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = m_gipTopLeft.Globalize(pPoint);
assert (SUCCEEDED(hr));
pPoint->Release();
// reference is now held in GIT
// теперь ссыпка хранится в GIT
// create instance of class Point
// создаем экземпляр класса Point
hr = CoCreateInstance(CLSID_Point, 0, CLSCTX_INPROC, IID_Iроint, (void**) &рРоint);
assert(SUCCEEDED(hr));
// register interface pointer in GIT
// регистрируем интерфейсный указатель в GIT
hr = m_gipBottomRight.Globalize(pPoint);
assert (SUCCEEDED (hr));
pPoint->Release();
// reference is now held in GIT
// теперь ссылка хранится в GIT
}
Те методы, которым нужен доступ к глобализованным указателям, могут импортировать локальную копию посредством метода Localize из GlobalInterfaсePointer:
STDMETHODIMP SafeRect::get_Top(long *pVal) {
IPoint *pPoint = 0;
// local imported pointer
// локальный импортированный указатель
HRESULT hr = m_gipTopLeft.Localize(&pPoint);
if (SUCCEEDED(hr)){
long x;
hr = pPoint->get_Coords(&x, pVal);
pPoint->Release(); }
return hr;
}
Отметим, что в силу применения маршалера свободной поточной обработки (FreeThreaded Marshaler) исходный интерфейсный указатель не может быть кэширован, а должен импортироваться при каждом вызове метода, чтобы предотвратить попытку доступа из неверного апартамента.
Предыдущий фрагмент кода может быть автоматизирован еще больше. Поскольку большинство вызовов методов в классе GlobalInterfacePointer должны будут локализовать временный указатель в самом вызове метода, то приводимый ниже класс автоматизирует импорт временного указателя и его последующее освобождение, что очень напоминает интеллектуальный указатель (smart pointer):
template <class Itf, const IID* piid> class LocalInterfacePointer {
Itf *m_pItf;
// temp imported pointer
// временный импортированный указатель
// prevent misuse
// предотвращаем неверное использование
LocalInterfacePointer(const LocalInterfacePointer&);
operator = (const LocalInterfacePointer&);
public:
LocalInterfacePointer(const GlobalInterfacePointer<Itf, piid>& rhs, HRESULT& hr) { hr = rhs.Loca1ize(&m_pItf) ; }
LocalInterfacePointer(DWORD dwCookie, HRESULT& hr) { assert(g_pGIT != 0);
hr = g_pGIT->GetInterfaceFromGlobal(dwCookie, *piid, (void**)&m_pItf); }
~LocalInterfacePointer(void) { if (m_pItf) m_pItf->Release(); }
class SafeItf : public Itf { STDMETHOD_(ULONG, AddRef) (void) = 0;
// hide
// скрытый STDMETHOD_(ULONG, Release)(void) = 0;
// hide
// скрытый
};
SafeItf *GetInterface(void) const { return (SafeItf*) m_pItf; }
SafeItf *operator ->(void) const { assert(m_pItf != 0);
return GetInterface();
}
};
#def1ne LIP(Itf) LocalInterfacePointer<Itf, &IID_##Itf>
С получением этого второго класса C++ обработка импортированных указателей становится намного проще:
STDMETHODIMP SafeRect::get_Area(long *pn) {
long top, left, bottom, right;
HRESULT hr, hr2;
// import pointers
// импортируем указатели
LIP(IPoint) lipTopLeft(m_gipTopLeft, hr);
LIP(IPoint) lipBottomRight(m_gipBottomRight, hr2);
assert(SUCCEEDED(hr) && SUCCEEDED(hr2));
// use temp tocal pointers
// используем временные локальные указатели
hr = lipTopLeft->GetCoords(&left, &top);
hr2 = lipBottomRight->GetCoords(&right, &bottom);
assert(SUCCEEDED(hr) && SUCCEEDED(hr2));
*pn = (right – left) * (bottom – top); return S_OK;
// LocalInterfacePointer auto-releases temp ptrs.
// LocalInterfacePointer сам освобождает
// временные указатели
}
Макросы GIP и LIP делают совместное использование GIT и FTM намного менее громоздким. До появления GIT использование FTM в классе с интерфейсными указателями было значительно более трудным, чем теперь обеспечивает любой из кодов, приведенных в данном разделе.
Где мы находимся?
В данной главе была описана абстракция апартаментов как логическое группирование объектов, которые подчиняются правилам параллелизма и реентерабельности. Процессы имеют один или более апартаментов. Потоки выполняются в ровно одном апартаменте, а для реализации межапартаментных связей СОМ поддерживает маршалинг объектных ссылок через границы апартаментов. Заместитель является локальным представителем объекта, постоянно находящимся в другом апартаменте. Стандартные заместители для передачи запросов методов с удаленного объекта используют ORPC. Специальные заместители имеют полную свободу для обеспечения корректной семантики. Апартамент является фундаментальной абстракцией, которая используется во всей архитектуре удаленного доступа модели СОМ.
Глава 6. Приложения
int process_id == fork();
if (process_id == 0)
exec(«…/bin/serverd»);
Аноним, 1981
В предыдущей главе были представлены основы апартаментов COM и проиллюстрирована COM-архитектура удаленного доступа с изрядным количеством деталей. Были исследованы правила управления ссылками на объекты COM в условиях многопоточной среды, а также методика реализации классов и объектов COM, работающих в потоках. В этой главе будут рассматриваться проблемы, возникающие при управлении процессами и приложениями при использовании COM. Основное внимание будет сосредоточено на том, как апартаменты соотносятся с локализацией ошибок, доверительными отношениями и контекстом защиты.
Подводные камни внутрипроцессной активации
Итак, серверы COM были ранее представлены как внутрипроцессные модули кода, загружаемые в активизирующий их процесс с целью создания объектов и выполнения их методов. Для значительного класса объектов это является разумной стратегией развертывания. Эта стратегия, однако, не лишена недостатков. Одним из подводных камней при запуске объекта в клиентском процессе является отсутствие изоляции ошибок. Если объект вызывает нарушение условий доступа или другую фатальную ошибку во время исполнения, то клиентский процесс завершится вместе с объектом. Более того, если программа клиента вызовет какую-либо ошибку, то все объекты, созданные в его адресном пространстве, будут немедленно уничтожены без предупреждения. Эта проблема также относится к тем клиентам, которые решат осуществить нормальный выход, например, когда конечный пользователь закрывает одно из приложений. Когда клиентский процесс завершается, любые объекты, созданные в адресном пространстве клиента, будут уничтожены, даже если внешние клиенты вне процесса хранят легальные импортированные ссылки. Очевидно, что если клиентский процесс прекратится, то при активизации внутри процесса жизнь объекта может быть прервана преждевременно.
Другая возможная ловушка при выполнении клиентского процесса состоит в совместном использовании контекста защиты. Когда клиент активизирует объект внутри процесса, методы объекта выполняются с использованием мандата (credential ) защиты клиента. Это означает, что объекты, созданные привилегированными пользователями, могут нанести значительные повреждения. Кроме того, это означает, что объекты, созданные клиентами с относительно меньшей степенью доверия, могут не получить достаточных привилегий для доступа к ресурсам, необходимым для корректного функционирования объекта. К сожалению, нет простого способа обеспечения внутрипроцессного объекта его собственным контекстом защиты.
Еще один подводный камень при внутрипроцессной активации состоит в том, что она не позволяет производить распределенные вычисления. Если объект должен быть активирован в адресном пространстве клиента, то по определению он разделит CPU (central processor unit – центральный процессор) и другие локальные ресурсы с клиентом. Внутрипроцессная активация также делает затруднительным совместное использование одного и того же объекта несколькими клиентскими процессами. Хотя понятие апартамента и допускает экспорт объектных ссылок из любого процесса (включая и те процессы, которые по традиции рассматривались как клиентские), тем не менее, трудно представить себе семантику активации для совместного использования внутрипроцессного экземпляра.
Для решения этих проблем COM допускает активацию классов в отдельных процессах. При активации в отдельном процессе каждый класс (или группа классов) может иметь свой отдельный контекст защиты. Это означает, что разработчик класса сам контролирует, каким пользователям позволено связываться с его объектами. Кроме того, разработчик класса контролирует, какой набор мандатов защиты должен использовать процесс. В зависимости от фактической упаковки класса разработчик класса также управляет тем, когда окружающий процесс закончится (и закончится ли вообще). Наконец, активация класса в отдельном процессе обеспечивает уровень изоляции ошибок, достаточный для изоляции клиента и объектов от завершения в результате ошибок друг друга.
Другая возможная ловушка при выполнении клиентского процесса состоит в совместном использовании контекста защиты. Когда клиент активизирует объект внутри процесса, методы объекта выполняются с использованием мандата (credential ) защиты клиента. Это означает, что объекты, созданные привилегированными пользователями, могут нанести значительные повреждения. Кроме того, это означает, что объекты, созданные клиентами с относительно меньшей степенью доверия, могут не получить достаточных привилегий для доступа к ресурсам, необходимым для корректного функционирования объекта. К сожалению, нет простого способа обеспечения внутрипроцессного объекта его собственным контекстом защиты.
Еще один подводный камень при внутрипроцессной активации состоит в том, что она не позволяет производить распределенные вычисления. Если объект должен быть активирован в адресном пространстве клиента, то по определению он разделит CPU (central processor unit – центральный процессор) и другие локальные ресурсы с клиентом. Внутрипроцессная активация также делает затруднительным совместное использование одного и того же объекта несколькими клиентскими процессами. Хотя понятие апартамента и допускает экспорт объектных ссылок из любого процесса (включая и те процессы, которые по традиции рассматривались как клиентские), тем не менее, трудно представить себе семантику активации для совместного использования внутрипроцессного экземпляра.
Для решения этих проблем COM допускает активацию классов в отдельных процессах. При активации в отдельном процессе каждый класс (или группа классов) может иметь свой отдельный контекст защиты. Это означает, что разработчик класса сам контролирует, каким пользователям позволено связываться с его объектами. Кроме того, разработчик класса контролирует, какой набор мандатов защиты должен использовать процесс. В зависимости от фактической упаковки класса разработчик класса также управляет тем, когда окружающий процесс закончится (и закончится ли вообще). Наконец, активация класса в отдельном процессе обеспечивает уровень изоляции ошибок, достаточный для изоляции клиента и объектов от завершения в результате ошибок друг друга.
Активация и SCM
Диспетчер управления COM-сервисами (Service Control Manager – SCM ) обеспечивает связь между CLSID и серверными процессами в реестре. Это позволяет SCM запускать серверный процесс при поступлении клиентских запросов на активацию. Если предположить, что код для класса будет упакован как образ процесса (ЕХЕ), а не как DLL, то достаточно использовать ключ реестра LocalServer32 вместо InprocServer32, как показано в следующем примере: