Страница:
// pseudo-code from OLE32.0LL
// псевдокод из OLE32.DLL
STDMETHODIMP GenericComposite::BindToObject (IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)
{
return m_pmkRight->BindToObject(pbc, m_pmkLeft, riid, ppv);
}
Эта реализация демонстрирует, что моникер справа является значащим только в области действия моникера, находящегося слева от него. В случае группового композитного моникера, использованного в данном примере, моникер элемента получит классовый моникер как параметр pmkToLeft во время связывания.
Ранее мы установили, что моникер элемента использует интерфейс IOleItemContainer для связывания интерфейсного указателя. Ниже приведен псевдокод для реализации моникера элемента ВindToObject:
// pseudo-code from OLE32.DLL
// псевдокод из OLE32.DLL
STDMETHODIMP ItemMoniker::BindToObject(
IBindCtx *pbc, IMoniker *pmkToLeft, REFIID riid, void **ppv)
{
// assume failure
// допускаем возможность сбоя
*ppv = 0;
if (pmkToLeft == 0)
//requires a scope – требуется область действия return
E_INVALIDARG;
// first bind moniker to left
// сначала привязываем моникер слева
IOleItemContainer *poic = 0;
HRESULT hr = pmkToLeft->BindToObject(pbc, 0, IID_IOleItemContainer, (void**)&poic);
if (SUCCEEDED(hr))
{
// cache the bound object in binding context
// кэшируем связанный объект в контексте связывания
pbc->RegisterObjectBound(poic);
// get bind speed from Bind Context
// получаем быстроту связывания из контекста связывания
DWORD dwBindSpeed = this->MyGetSpeedFromCtx(pbc);
// ask object for named sub-object
// запрашиваем объект об именованном подобъекте
hr = poic->GetObject(m_pszItem, dwBindSpeed, pbc, riid, ppv);
poic->Release();
}
}
Эта реализация означает, что такой код:
HRESULT GetUrsus(IApe *&rpApe)
{
const OLECHAR pwsz[] = OLESTR(«clsid:571F1680-CC83-11d0-8C48-0080C73925BA:!Ursus»);
return CoGetObject(pwsz, 0, IID_IApe, (void**)&rpApe);
}
эквивалентен следующему:
HRESULT GetUrsus(IApe *&rpApe) {
IOleItemContainer *poic = 0;
HRESULT hr = CoGetClassObject(CLSID_Gorilla, CLSCTX_ALL,
0, IID_IOleItemContainer, (void**)&poic);
if (SUCCEEDED(hr)) {
hr = poic->GetObject(OLESTR(«Ursus»), BINDSPEED_INFINITE,
0, IID_IApe, (void**)&rpApe);
poic->Release();
}
return hr; }
Отметим, что уровень изоляции (indirection), обеспеченный использованием CoGetObject, позволяет клиенту менять стратегию связывания просто путем чтения различных отображаемых имен из файла конфигурации или из ключа реестра.
Моникеры и сохраняемость
Обсуждение моникеров не может быть полным без обсуждения файлового моникера (File Moniker). Напомним, что СОМ предусматривает три примитива активации: привязывание к объектам класса, привязывание к новым экземплярам класса и привязывание к постоянным объектам, хранящимся в файлах. В данной главе детально анализировались первые два из этих примитивов. Третий примитив основан на API-функции СОМ CoGetInstanceFromFile:
HRESULT CoGetInstanceFromFile( [in, unique] COSERVERINFO *pcsi,
// host/security info – информация о хосте/безопасности
[in, unique] CLSID *pClsid,
// explicit CLSID (opt) – явный CLSID (opt)
[in, unique] IUnknown *punk0uter,
// for aggregation – для агрегирования
[in] DWORD dwClsCtx,
// locality? – локализация?
[in] DWORD grfMode,
// file open mode – режим открытия файла
[in] OLECHAR *pwszName,
// file name of object – файловое имя объекта
[in] DWORD cmqi,
// how many interfaces? – сколько интерфейсов?
[out, size_is(cmqi)] MULTI_QI *prgmq
// where to put itfs – куда поместить интерфейсы
);
Эта функция принимает на вход имя файла, которое относится к постоянному состоянию (persistent state) объекта[1]. CoGetInstanceFromFile удостоверяется в том, что объект исполняется, после чего возвращает один или несколько интерфейсных указателей на (ре)активированный объект. Чтобы выполнить эту работу, CoGetInstanceFromFile в первую очередь требуется определить CLSID данного объекта. CLSID требуется по двум причинам. Если объект не исполняется, то CLSID необходим СОМ для создания нового экземпляра, который будет инициализирован от постоянного (находящегося в файле) образа. Во-вторых, если вызывающий объект не указывает определенное хост-имя до запроса на активацию, то СОМ будет использовать CLSID для выяснения того, на какой машине следует активировать объект[2].
Если CLSID не передается явно вызывающим объектом, то CoGetInstanceFromFile извлекает CLSID из самого файла с помощью вызова API-функции СОМ GetClassFile:
HRESULT GetClassFile([in, string) OLECHAR *pwszFileName, [out] CLSID *pclsid);
Для определения типа объекта, содержащегося в файле, GetClassFile использует информацию из заголовка файла, а также информацию из реестра.
После того как определены класс и хост-машина, СОМ исследует ROT (Running Object Table – таблица исполняющихся объектов) на целевой хост-машине для того, чтобы выяснить, является ли объект уже активированным. Таблица ROT является инструментом SCM, который преобразует произвольные моникеры в экземпляры объектов, исполняющихся на локальной хост-машине. Ожидается, что постоянные объекты будут регистрировать себя в локальной ROT во время загрузки. Чтобы представить файловое имя постоянного объекта в качестве моникера, СОМ предусматривает стандартный тип моникера – файловый моникер, который оборачивает имя файла в интерфейс IMoniker. Файловые моникеры могут создаваться либо путем передачи файлового имени в МkParseDisplayName , либо вызовом явной API-функции CreateFileMoniker:
HRESULT CreateFileMoniker( [in, string] const OLECHAR *pszFileName, [out] IMoniker **ppmk);
Если постоянный объект уже зарегистрировал в ROT свой файловый моникер, то CoGetInstanceFromFile просто возвращает указатель на уже работающий объект. Если же объект в ROT не найден, то СОМ создает новый экземпляр файлового класса и инициализирует его из постоянного объекта с помощью метода IPersistFile::Load этого экземпляра:
[object, uuid(0000010b-0000-0000-C000-000000000046)]
interface IPersistFile : IPersist
{
// called by CoGetInstanceFromFile to initialize object
// вызывается функцией CoGetInstanceFromFile для
// инициализации объекта
HRESULT Load(
[in, string] const OLECHAR * pszFileName, [in] DWORD grfMode
);
// remaining methods deleted for clarity // остальные методы удалены для ясности
}
Реализация объекта отвечает за загрузку из файла всех постоянных элементов и за саморегистрацию в локальной таблице ROT – с целью убедиться, что для каждого файла в каждый момент может исполняться только один экземпляр:
STDMETHODIMP::Load(const OLECHAR *pszFileName, DWORD grfMode)
{
// read in persisted object state
// считываем сохраненное состояние объекта
HRESULT hr = this->MyReadStateFromFile(pszFile, grfMode);
if (FAILED(hr)) return hr;
// get pointer to ROT from SCM
// берем указатель на ROT от SCM
IRunningObjectTable *prot = 0;
hr = GetRunningObjectTable(0, &prot);
if (SUCCEEDED(hr))
{
// create a file moniker to register in ROT
// создаем файловый моникер для регистрации в ROT
IMoniker *pmk = 0;
hr = CreateFileMoniker(pszFileName, &pmk);
if (SUCCEEDED(hr))
{
// register self in ROT
// саморегистрация в ROT
hr = prot->Register(0, this, pmk, &m_dwReg);
pmk->Release();
}
prot->Release();
}
return hr;
}
Метод IPersistFile::Load нового созданного экземпляра будет вызван диспетчером SCM во время выполнения CoGetInstanceFromFile . В приведенном выше примере для получения указателя на интерфейс IRunningObjectTable в SCM используется API-функция СОМ GetRunningObjectTable. Этот интерфейс затем используется для регистрации своего моникера в ROT, так что последующие вызовы CoGetInstanceFromFile , использующие то же файловое имя, не будут создавать новые объекты, а вместо этого возвратят ссылки на этот объект[3].
Существование File Moniker обусловлено двумя причинами. Во-первых, он нужен, чтобы позволить объектам самим регистрироваться в ROT, чтобы их мог найти CoGetInstanceFromFile. Во-вторых, чтобы скрыть от клиента использование CoGetInstanceFromFile за интерфейсом IMoniker. Реализация File Moniker из BindToObject просто вызывает CoGetInstanceFromFile:
// pseudo-code from OLE32.DLL // псевдокод из OLE32.DLL
STDMETHODIMP FileMoniker::BindToObject(IBindCtx *pbc,
IMoniker *pmkToLeft,
REFIID riid, void **ppv) {
// assume failure – на случай сбоя
*ppv = О;
HRESULT hr = E_FAIL;
if (pmkToLeft == 0) {
// no moniker to left – слева моникеров нет
MULTI_QI mqi = { &riid, 0, 0 };
COSERVERINFO *pcsi;
DWORD grfMode;
DWORD dwClsCtx;
// these three parameters are attributes of the BindCtx
// эти три параметра являются атрибутами BindCtx
this->MyGetFromBindCtx(pbc, &pcsi, &grfMode, &dwClsCtx);
hr = CoGetInstanceFromFile(pcsi, 0, 0, dwClsCtx,
grfMode, this->m_pszFileName,
1, &mqi);
if (SUCCEEDED(hr))
*ppv = mqi.pItf;
} else {
// there's a moniker to the left – слева есть моникер
// ask object to left for IClassActivator
// or IClassFactory
// запрашиваем объект слева от IClassActivator или от
// IClassFactory
}
return hr; }
При таком поведении File Moniker следующая функция, вызывающая CoGetInstanceFromFile
HRESULT GetCornelius(IApe * &rpApe)
{
OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);
MULTI_QI mqi = { &IID_IApe, 0, 0 };
HRESULT hr = CoGetInstanceFromFile(0, 0, 0, CLSCTX_SERVER, STCM_READWRITE, pwszObject, 1, &mqi);
if (SUCCEEDED(hr)) rpApe = mqi.pItf;
else rpApe = 0;
return hr;
}
может быть упрощена, если вместо этого использовать вызов CoGetObject:
HRESULT GetCornelius(IApe * &rpApe)
{
OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);
return CoGetObject(pwszObject, 0, IID_IApe, (void**)&rpApe);
}
Как и в предыдущем случае, когда использовался Class Moniker, уровень изоляции, обеспеченный CoGetObject, позволяет клиенту задавать сколь угодно сложную стратегию активации, не меняя ни единой строки кода.
HRESULT CoGetInstanceFromFile( [in, unique] COSERVERINFO *pcsi,
// host/security info – информация о хосте/безопасности
[in, unique] CLSID *pClsid,
// explicit CLSID (opt) – явный CLSID (opt)
[in, unique] IUnknown *punk0uter,
// for aggregation – для агрегирования
[in] DWORD dwClsCtx,
// locality? – локализация?
[in] DWORD grfMode,
// file open mode – режим открытия файла
[in] OLECHAR *pwszName,
// file name of object – файловое имя объекта
[in] DWORD cmqi,
// how many interfaces? – сколько интерфейсов?
[out, size_is(cmqi)] MULTI_QI *prgmq
// where to put itfs – куда поместить интерфейсы
);
Эта функция принимает на вход имя файла, которое относится к постоянному состоянию (persistent state) объекта[1]. CoGetInstanceFromFile удостоверяется в том, что объект исполняется, после чего возвращает один или несколько интерфейсных указателей на (ре)активированный объект. Чтобы выполнить эту работу, CoGetInstanceFromFile в первую очередь требуется определить CLSID данного объекта. CLSID требуется по двум причинам. Если объект не исполняется, то CLSID необходим СОМ для создания нового экземпляра, который будет инициализирован от постоянного (находящегося в файле) образа. Во-вторых, если вызывающий объект не указывает определенное хост-имя до запроса на активацию, то СОМ будет использовать CLSID для выяснения того, на какой машине следует активировать объект[2].
Если CLSID не передается явно вызывающим объектом, то CoGetInstanceFromFile извлекает CLSID из самого файла с помощью вызова API-функции СОМ GetClassFile:
HRESULT GetClassFile([in, string) OLECHAR *pwszFileName, [out] CLSID *pclsid);
Для определения типа объекта, содержащегося в файле, GetClassFile использует информацию из заголовка файла, а также информацию из реестра.
После того как определены класс и хост-машина, СОМ исследует ROT (Running Object Table – таблица исполняющихся объектов) на целевой хост-машине для того, чтобы выяснить, является ли объект уже активированным. Таблица ROT является инструментом SCM, который преобразует произвольные моникеры в экземпляры объектов, исполняющихся на локальной хост-машине. Ожидается, что постоянные объекты будут регистрировать себя в локальной ROT во время загрузки. Чтобы представить файловое имя постоянного объекта в качестве моникера, СОМ предусматривает стандартный тип моникера – файловый моникер, который оборачивает имя файла в интерфейс IMoniker. Файловые моникеры могут создаваться либо путем передачи файлового имени в МkParseDisplayName , либо вызовом явной API-функции CreateFileMoniker:
HRESULT CreateFileMoniker( [in, string] const OLECHAR *pszFileName, [out] IMoniker **ppmk);
Если постоянный объект уже зарегистрировал в ROT свой файловый моникер, то CoGetInstanceFromFile просто возвращает указатель на уже работающий объект. Если же объект в ROT не найден, то СОМ создает новый экземпляр файлового класса и инициализирует его из постоянного объекта с помощью метода IPersistFile::Load этого экземпляра:
[object, uuid(0000010b-0000-0000-C000-000000000046)]
interface IPersistFile : IPersist
{
// called by CoGetInstanceFromFile to initialize object
// вызывается функцией CoGetInstanceFromFile для
// инициализации объекта
HRESULT Load(
[in, string] const OLECHAR * pszFileName, [in] DWORD grfMode
);
// remaining methods deleted for clarity // остальные методы удалены для ясности
}
Реализация объекта отвечает за загрузку из файла всех постоянных элементов и за саморегистрацию в локальной таблице ROT – с целью убедиться, что для каждого файла в каждый момент может исполняться только один экземпляр:
STDMETHODIMP::Load(const OLECHAR *pszFileName, DWORD grfMode)
{
// read in persisted object state
// считываем сохраненное состояние объекта
HRESULT hr = this->MyReadStateFromFile(pszFile, grfMode);
if (FAILED(hr)) return hr;
// get pointer to ROT from SCM
// берем указатель на ROT от SCM
IRunningObjectTable *prot = 0;
hr = GetRunningObjectTable(0, &prot);
if (SUCCEEDED(hr))
{
// create a file moniker to register in ROT
// создаем файловый моникер для регистрации в ROT
IMoniker *pmk = 0;
hr = CreateFileMoniker(pszFileName, &pmk);
if (SUCCEEDED(hr))
{
// register self in ROT
// саморегистрация в ROT
hr = prot->Register(0, this, pmk, &m_dwReg);
pmk->Release();
}
prot->Release();
}
return hr;
}
Метод IPersistFile::Load нового созданного экземпляра будет вызван диспетчером SCM во время выполнения CoGetInstanceFromFile . В приведенном выше примере для получения указателя на интерфейс IRunningObjectTable в SCM используется API-функция СОМ GetRunningObjectTable. Этот интерфейс затем используется для регистрации своего моникера в ROT, так что последующие вызовы CoGetInstanceFromFile , использующие то же файловое имя, не будут создавать новые объекты, а вместо этого возвратят ссылки на этот объект[3].
Существование File Moniker обусловлено двумя причинами. Во-первых, он нужен, чтобы позволить объектам самим регистрироваться в ROT, чтобы их мог найти CoGetInstanceFromFile. Во-вторых, чтобы скрыть от клиента использование CoGetInstanceFromFile за интерфейсом IMoniker. Реализация File Moniker из BindToObject просто вызывает CoGetInstanceFromFile:
// pseudo-code from OLE32.DLL // псевдокод из OLE32.DLL
STDMETHODIMP FileMoniker::BindToObject(IBindCtx *pbc,
IMoniker *pmkToLeft,
REFIID riid, void **ppv) {
// assume failure – на случай сбоя
*ppv = О;
HRESULT hr = E_FAIL;
if (pmkToLeft == 0) {
// no moniker to left – слева моникеров нет
MULTI_QI mqi = { &riid, 0, 0 };
COSERVERINFO *pcsi;
DWORD grfMode;
DWORD dwClsCtx;
// these three parameters are attributes of the BindCtx
// эти три параметра являются атрибутами BindCtx
this->MyGetFromBindCtx(pbc, &pcsi, &grfMode, &dwClsCtx);
hr = CoGetInstanceFromFile(pcsi, 0, 0, dwClsCtx,
grfMode, this->m_pszFileName,
1, &mqi);
if (SUCCEEDED(hr))
*ppv = mqi.pItf;
} else {
// there's a moniker to the left – слева есть моникер
// ask object to left for IClassActivator
// or IClassFactory
// запрашиваем объект слева от IClassActivator или от
// IClassFactory
}
return hr; }
При таком поведении File Moniker следующая функция, вызывающая CoGetInstanceFromFile
HRESULT GetCornelius(IApe * &rpApe)
{
OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);
MULTI_QI mqi = { &IID_IApe, 0, 0 };
HRESULT hr = CoGetInstanceFromFile(0, 0, 0, CLSCTX_SERVER, STCM_READWRITE, pwszObject, 1, &mqi);
if (SUCCEEDED(hr)) rpApe = mqi.pItf;
else rpApe = 0;
return hr;
}
может быть упрощена, если вместо этого использовать вызов CoGetObject:
HRESULT GetCornelius(IApe * &rpApe)
{
OLECHAR *pwszObject = OLESTR(\\\\server\\public\\cornelius.chmp);
return CoGetObject(pwszObject, 0, IID_IApe, (void**)&rpApe);
}
Как и в предыдущем случае, когда использовался Class Moniker, уровень изоляции, обеспеченный CoGetObject, позволяет клиенту задавать сколь угодно сложную стратегию активации, не меняя ни единой строки кода.
Время жизни сервера
В предыдущих разделах было показано, как СОМ автоматически загружает DLL с целью перенесения реализации объектов в адресное пространство клиентских программ. Однако пока не обсуждалось, как и когда эти DLL выгружаются. Вообще говоря, серверные DLL могут предотвращать преждевременную выгрузку, но именно клиент выбирает момент, когда DLL фактически перестают использоваться. Клиенты, желающие освободить неиспользуемые DLL, вызывают API-функцию СОМ CoFreeUnusedLibraries:
void CoFreeUnusedLibraries(void);
Обычно эта подпрограмма вызывается клиентами в свободное время с целью собрать мусор в своем адресном пространстве. При вызове CoFreeUnusedLibraries СОМ опрашивает каждую из загруженных DLL, чтобы выявить, какие из них не используются. Это делается посредством вызова в каждой DLL функции DllCanUnloadNow, которая должна быть явно экспортирована из этой динамически подключаемой библиотеки.
Функция DllCanUnloadNow, которую экспортирует DLL каждого сервера, должна соответствовать следующей сигнатуре:
HRESULT DllCanUnloadNow(void);
Если DLL желает быть освобожденной, то она возвращает S_OK. Если DLL хочет остаться загруженной, то она возвращает S_FALSE. Серверные DLL должны оставаться загруженными по крайней мере до тех пор, пока сохраняются интерфейсные указатели на ее объекты. Это означает, что в DLL должен быть счетчик всех существующих ссылок на объекты. Чтобы упростить реализацию этого, большинство DLL содержат одну переменную для счетчика блокировок (lock count) и используют две функции для автоматического инкрементирования и декрементирования этого счетчика:
LONG g_cLocks = 0; void LockModule(void)
{ InterlockedIncrement(&g_cLocks); }
void UnlockModule(void)
{ InterlockedDecrement(&g_cLocks); }
При наличии этих подпрограмм реализация DllCanUnloadNow становится чрезвычайно простой:
STDAPI DllCanUnloadNow(void)
{ return g_cLocks == 0 ? S_OK : S_FALSE; }
Oстается только вызывать в подходящее время подпрограммы LockModule и UnlockModule.
Существуют две основные причины, которые должны оставлять DLL сервера загруженной: внешние ссылки на экземпляры объектов и объекты класса, а также невыполненные вызовы IClassFactory::LockServer. Вполне очевидно, как добавить поддержку DllCanUnloadNow в экземпляры и объекты классов. Объекты, расположенные в динамически распределяемой области памяти (такие, как экземпляры классов) просто инкрементируют счетчик блокировок сервера при первом вызове AddRef:
STDMETHODIMP_(ULONG) Chimp::AddRef(void)
{ if (m_cRef == 0) LockModule(); return InterlockedIncrement(&m_cRef); }
и декрементируют счетчик блокировок при заключительном вызове Release:
STDMETHODIMP_(ULONG) Chimp::Release (void)
{ LONG res = InterlockedDecrement(&m_cRef); if (res == 0)
{ delete this; UnlockModule(); }
return res; }
Поскольку объекты, не размещенные в динамически распределяемой области памяти (такие, как объекты классов), не содержат счетчика ссылок, при каждом вызове AddRef и Release нужно инкрементировать или декрементировать счетчик блокировок:
STDMETHODIMP_(ULONG) ChimpClass::AddRef(void) {
LockModule();
return 2;
}
STDMETHODIMP_(ULONG) ChimpClass::Release (void) {
UnlockModule();
return 1;
}
Объекты классов, которые реализуют IClassFactory, должны устанавливать свои серверные счетчики блокировок на вызовы IClassFactory::LockServer:
STDMETHODIMP ChimpClass::LockServer(BOOL bLock)
{
if (bLock) LockModule();
else UnlockModule();
return S_OK;
}
Как будет обсуждаться в главе 6, IClassFactory::LockServer создана в первую очередь для внепроцессных серверов, но она достаточно проста и для использования во внутрипроцессных серверах.
Следует заметить, что в протоколе CoFreeUnusedLibraries/DllCanUnloadNow неотъемлемо присутствует состояние гонки (race condition). Возможно, что один поток задач будет выполнять заключительное освобождение последнего экземпляра, экспортированного из DLL, в то время как второй поток будет выполнять подпрограмму CoFreeUnusedLibraries. В СОМ приняты все меры предосторожности, чтобы избежать этой ситуации. В частности, в реализацию СОМ под Windows NT 4.0 Service Pack 2 добавлена специальная возможность для борьбы с состоянием гонки. Версия Service Pack 2 библиотеки СОМ определяет, чтобы к DLL обращались из нескольких потоков, и вместо того, чтобы незамедлительно выгружать DLL изнутри CoFreeUnusedLibraries, СОМ ставит DLL в очередь DLL, подлежащих освобождению. Затем СОМ будет ждать неопределенное время, пока не разрешит этим неиспользуемым серверным DLL освободиться посредством последующего вызова CoFreeUnusedLibraries, подтверждающего, что никаких остаточных вызовов Release уже не исполняется[1]. Это означает, что в многопоточных средах выгрузка DLL из своего клиента может осуществляться значительно дольше, чем можно ожидать.
void CoFreeUnusedLibraries(void);
Обычно эта подпрограмма вызывается клиентами в свободное время с целью собрать мусор в своем адресном пространстве. При вызове CoFreeUnusedLibraries СОМ опрашивает каждую из загруженных DLL, чтобы выявить, какие из них не используются. Это делается посредством вызова в каждой DLL функции DllCanUnloadNow, которая должна быть явно экспортирована из этой динамически подключаемой библиотеки.
Функция DllCanUnloadNow, которую экспортирует DLL каждого сервера, должна соответствовать следующей сигнатуре:
HRESULT DllCanUnloadNow(void);
Если DLL желает быть освобожденной, то она возвращает S_OK. Если DLL хочет остаться загруженной, то она возвращает S_FALSE. Серверные DLL должны оставаться загруженными по крайней мере до тех пор, пока сохраняются интерфейсные указатели на ее объекты. Это означает, что в DLL должен быть счетчик всех существующих ссылок на объекты. Чтобы упростить реализацию этого, большинство DLL содержат одну переменную для счетчика блокировок (lock count) и используют две функции для автоматического инкрементирования и декрементирования этого счетчика:
LONG g_cLocks = 0; void LockModule(void)
{ InterlockedIncrement(&g_cLocks); }
void UnlockModule(void)
{ InterlockedDecrement(&g_cLocks); }
При наличии этих подпрограмм реализация DllCanUnloadNow становится чрезвычайно простой:
STDAPI DllCanUnloadNow(void)
{ return g_cLocks == 0 ? S_OK : S_FALSE; }
Oстается только вызывать в подходящее время подпрограммы LockModule и UnlockModule.
Существуют две основные причины, которые должны оставлять DLL сервера загруженной: внешние ссылки на экземпляры объектов и объекты класса, а также невыполненные вызовы IClassFactory::LockServer. Вполне очевидно, как добавить поддержку DllCanUnloadNow в экземпляры и объекты классов. Объекты, расположенные в динамически распределяемой области памяти (такие, как экземпляры классов) просто инкрементируют счетчик блокировок сервера при первом вызове AddRef:
STDMETHODIMP_(ULONG) Chimp::AddRef(void)
{ if (m_cRef == 0) LockModule(); return InterlockedIncrement(&m_cRef); }
и декрементируют счетчик блокировок при заключительном вызове Release:
STDMETHODIMP_(ULONG) Chimp::Release (void)
{ LONG res = InterlockedDecrement(&m_cRef); if (res == 0)
{ delete this; UnlockModule(); }
return res; }
Поскольку объекты, не размещенные в динамически распределяемой области памяти (такие, как объекты классов), не содержат счетчика ссылок, при каждом вызове AddRef и Release нужно инкрементировать или декрементировать счетчик блокировок:
STDMETHODIMP_(ULONG) ChimpClass::AddRef(void) {
LockModule();
return 2;
}
STDMETHODIMP_(ULONG) ChimpClass::Release (void) {
UnlockModule();
return 1;
}
Объекты классов, которые реализуют IClassFactory, должны устанавливать свои серверные счетчики блокировок на вызовы IClassFactory::LockServer:
STDMETHODIMP ChimpClass::LockServer(BOOL bLock)
{
if (bLock) LockModule();
else UnlockModule();
return S_OK;
}
Как будет обсуждаться в главе 6, IClassFactory::LockServer создана в первую очередь для внепроцессных серверов, но она достаточно проста и для использования во внутрипроцессных серверах.
Следует заметить, что в протоколе CoFreeUnusedLibraries/DllCanUnloadNow неотъемлемо присутствует состояние гонки (race condition). Возможно, что один поток задач будет выполнять заключительное освобождение последнего экземпляра, экспортированного из DLL, в то время как второй поток будет выполнять подпрограмму CoFreeUnusedLibraries. В СОМ приняты все меры предосторожности, чтобы избежать этой ситуации. В частности, в реализацию СОМ под Windows NT 4.0 Service Pack 2 добавлена специальная возможность для борьбы с состоянием гонки. Версия Service Pack 2 библиотеки СОМ определяет, чтобы к DLL обращались из нескольких потоков, и вместо того, чтобы незамедлительно выгружать DLL изнутри CoFreeUnusedLibraries, СОМ ставит DLL в очередь DLL, подлежащих освобождению. Затем СОМ будет ждать неопределенное время, пока не разрешит этим неиспользуемым серверным DLL освободиться посредством последующего вызова CoFreeUnusedLibraries, подтверждающего, что никаких остаточных вызовов Release уже не исполняется[1]. Это означает, что в многопоточных средах выгрузка DLL из своего клиента может осуществляться значительно дольше, чем можно ожидать.
Классы и IDL
Как уже отмечалось в начале этой главы, СОМ рассматривает интерфейсы и классы как отдельные сущности. В свете этого классы СОМ (а равно и интерфейсы СОМ) должны быть определены в IDL с целью обеспечить независимое от языка описание конкретных типов данных, которые может экспортировать сервер. IDL-определение класса СОМ содержит список интерфейсов, которые экспортируются элементами класса, исключая катастрофический сбой:
[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)]
coclass Gorilla { interface IApe; interface IWarrior; }
IDL -определения коклассов (coclass) всегда появляются в контексте определения библиотеки (library definition). В IDL определения библиотек используются для группирования набора типов данных (например, интерфейсы, коклассы, определения типов) в логический блок или пространство имен. Все типы данных, появляющиеся в контексте определения библиотеки IDL, будут отмечены в результирующей библиотеке типов. Библиотеки типов используются вместо IDL-файлов такими средами, как Visual Basic и Java.
Как правило, IDL-файл может содержать один библиотечный оператор, и все типы данных, определенные или использованные внутри определения библиотек, появятся в генерируемой библиотеке типа:
// apes.idl // bring in IDL definitions of ape interfaces
// введем IDL-определения интерфейсов обезьян
import «apeitfs.idl»;
[ uuid(753A8A80-A7FF-11d0-8C30-0080C73925BA),
// LIBID – идентификатор библиотеки version(1.0),
// version number of library – номер версии библиотеки
lcid(9),
// locale ID of library (english)
// код локализации библиотеки (english)
helpstring(«Library of the Apes»)
// title of library – заголовок библиотеки
]
library ApeLib { importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные опредепения
[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla {
[default] interface IApe;
interface IWarrior; }
[uuid(753A8A7E-A7FF-11d0-8C30-0080C73925BA)] coclass Chimpanzee {
[default] interface IApe;
interface IEgghead; }
[uuid(753A8A7F-A7FF-11d0-8C30-O080C73925BA)] coclass Orangutan {
[default] interface IApe;
interface IKeeperOfTheFaith; } }
Атрибут [default] показывает, какой из интерфейсов наиболее близко представляет внутренний тип класса. В тех языках, которые распознают этот атрибут, [default] позволяет программисту объявлять ссылки объекта, используя только имя кокласса СОМ:
Dim ursus as Gorilla
Исходя из IDL-определения для Gorilla, данный оператор эквивалентен следующему:
Dim ursus as IApe
поскольку IApe является интерфейсом по умолчанию для класса Gorilla. В любом случае программист мог вызывать методы EatBanana и SwingFromTree с переменной ursus. Если атрибут [default] не указан, то он неявно добавляется к первому интерфейсу в определении coclass.
Имея указанное выше библиотечное определение IDL, результирующий заголовочный файл apes.h будет использовать препроцессор С для включения файла apesitfs.h. Этот файл apesitfs.h будет содержать определения абстрактных базовых классов для четырех интерфейсов СОМ IApe, IWarrior, IKeeperOfTheFaith и IEgghead. Кроме того, файл apes.h будет содержать объявления GUID для каждого класса:
extern "С" const CLSID CLSID_Gorilla;
extern "С" const CLSID CLSID_Chimpanzee;
extern "С" const CLSID CLSID_Orangutan;
Соответствующий файл apes_i.с будет содержать определения этих CLSID. Сгенерированная библиотека типов apes.tlb будет содержать описания каждого из интерфейсов и классов, что позволит программисту на Visual Basic написать следующее:
Dim ape As IApe
Dim warrior as IWarrior
Set ape = New Gorilla
' ask СОМ for a new gorilla
' запрашиваем СОМ о новой
gorilla Set warrior = ape
А вот так выглядит Java-версия того же самого кода:
IАре аре;
IWarrior warrior;
аре = new Gorilla();
// no cast needed for [default]
// никаких приведений не требуется для [default] ???
warrior = (IWarrior)ape;
Оба этих фрагмента кода предписывают виртуальной машине использовать CLSID_Gorilla для сообщения CoCreateInstanceEx о том, какой тип объекта нужно создать.
В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика – определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, – использовать директиву importlib:
// humans.idl
// apeitfs.idl DOESN'T have a library statement, so import
// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем
import «apeitfs.idl»;
[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)
// «Люди, нуждающиеся в обезьянах»
]
library HumanLib {
importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные определения
// Dogs.idl DOES have a library definition, so importlib
// its corresponding type library
// Dogs.idl ИМЕЕТ определение библиотеки, поэтому
// импортируем библиотеку соответствующего типа
importlib(«dogs.tlb»);
[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]
coclass DogApe {
interface IDog;
interface IApe;
} }
В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.
[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)]
coclass Gorilla { interface IApe; interface IWarrior; }
IDL -определения коклассов (coclass) всегда появляются в контексте определения библиотеки (library definition). В IDL определения библиотек используются для группирования набора типов данных (например, интерфейсы, коклассы, определения типов) в логический блок или пространство имен. Все типы данных, появляющиеся в контексте определения библиотеки IDL, будут отмечены в результирующей библиотеке типов. Библиотеки типов используются вместо IDL-файлов такими средами, как Visual Basic и Java.
Как правило, IDL-файл может содержать один библиотечный оператор, и все типы данных, определенные или использованные внутри определения библиотек, появятся в генерируемой библиотеке типа:
// apes.idl // bring in IDL definitions of ape interfaces
// введем IDL-определения интерфейсов обезьян
import «apeitfs.idl»;
[ uuid(753A8A80-A7FF-11d0-8C30-0080C73925BA),
// LIBID – идентификатор библиотеки version(1.0),
// version number of library – номер версии библиотеки
lcid(9),
// locale ID of library (english)
// код локализации библиотеки (english)
helpstring(«Library of the Apes»)
// title of library – заголовок библиотеки
]
library ApeLib { importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные опредепения
[uuid(753A8A7D-A7FF-11d0-8C30-0080C73925BA)] coclass Gorilla {
[default] interface IApe;
interface IWarrior; }
[uuid(753A8A7E-A7FF-11d0-8C30-0080C73925BA)] coclass Chimpanzee {
[default] interface IApe;
interface IEgghead; }
[uuid(753A8A7F-A7FF-11d0-8C30-O080C73925BA)] coclass Orangutan {
[default] interface IApe;
interface IKeeperOfTheFaith; } }
Атрибут [default] показывает, какой из интерфейсов наиболее близко представляет внутренний тип класса. В тех языках, которые распознают этот атрибут, [default] позволяет программисту объявлять ссылки объекта, используя только имя кокласса СОМ:
Dim ursus as Gorilla
Исходя из IDL-определения для Gorilla, данный оператор эквивалентен следующему:
Dim ursus as IApe
поскольку IApe является интерфейсом по умолчанию для класса Gorilla. В любом случае программист мог вызывать методы EatBanana и SwingFromTree с переменной ursus. Если атрибут [default] не указан, то он неявно добавляется к первому интерфейсу в определении coclass.
Имея указанное выше библиотечное определение IDL, результирующий заголовочный файл apes.h будет использовать препроцессор С для включения файла apesitfs.h. Этот файл apesitfs.h будет содержать определения абстрактных базовых классов для четырех интерфейсов СОМ IApe, IWarrior, IKeeperOfTheFaith и IEgghead. Кроме того, файл apes.h будет содержать объявления GUID для каждого класса:
extern "С" const CLSID CLSID_Gorilla;
extern "С" const CLSID CLSID_Chimpanzee;
extern "С" const CLSID CLSID_Orangutan;
Соответствующий файл apes_i.с будет содержать определения этих CLSID. Сгенерированная библиотека типов apes.tlb будет содержать описания каждого из интерфейсов и классов, что позволит программисту на Visual Basic написать следующее:
Dim ape As IApe
Dim warrior as IWarrior
Set ape = New Gorilla
' ask СОМ for a new gorilla
' запрашиваем СОМ о новой
gorilla Set warrior = ape
А вот так выглядит Java-версия того же самого кода:
IАре аре;
IWarrior warrior;
аре = new Gorilla();
// no cast needed for [default]
// никаких приведений не требуется для [default] ???
warrior = (IWarrior)ape;
Оба этих фрагмента кода предписывают виртуальной машине использовать CLSID_Gorilla для сообщения CoCreateInstanceEx о том, какой тип объекта нужно создать.
В предыдущем IDL на каждый из интерфейсов IApe, IWarrior, IEgghead и IKeeperOfTheFaith есть ссылки из определения библиотеки. По этой причине их определения присутствуют в генерируемой библиотеке типов, несмотря та то, что они определены вне области действия определения библиотеки. В действительности любые типы данных, используемые как параметры или как базовые интерфейсы для данных интерфейсов, будут в то же время присутствовать в генерируемой библиотеке. Существует хорошая практика – определять оператор с реализацией библиотеки в отдельном IDL-файле, который импортирует все необходимые определения интерфейсов из внешнего IDL-файла, содержащего только описания интерфейсов. Такая практика является обязательной в больших проектах со многими IDL-файлами, так как для IDL-файла, содержащего определение библиотеки, недопустимо импортировать другой IDL-файл, который также содержит определение библиотеки. Путем разделения определений библиотеки по отдельным IDL-файлам можно корректно импортировать интерфейсы, используемые библиотекой, в другие проекты, не беспокоясь о множественных определениях библиотеки. Если не использовать этот способ, то существует только одна возможность импортировать определение интерфейса из IDL-файла, содержащего определение библиотеки, – использовать директиву importlib:
// humans.idl
// apeitfs.idl DOESN'T have a library statement, so import
// apeitfs.idl HE ИМЕЕТ оператора library, поэтому импортируем
import «apeitfs.idl»;
[ uuid(753A8AC9-A7FF-11d0-8C30-0080C73925BA), version(1.0), lcld(9), helpstring(«Humans that need apes»)
// «Люди, нуждающиеся в обезьянах»
]
library HumanLib {
importlib(«stdole32.tlb»);
// bring in std defs. – вносим стандартные определения
// Dogs.idl DOES have a library definition, so importlib
// its corresponding type library
// Dogs.idl ИМЕЕТ определение библиотеки, поэтому
// импортируем библиотеку соответствующего типа
importlib(«dogs.tlb»);
[uuid(753A8AD1-A7FF-11d0-8C30-0080C73925BA)]
coclass DogApe {
interface IDog;
interface IApe;
} }
В простых проектах часто используется один IDL-файл, в котором определяются как интерфейсы, так и классы, экспортируемые из проекта. Для простых интерфейсов это имеет смысл, так как генерируемая библиотека типов будет содержать взаимно однозначные образы исходных определений IDL, что позволит пользователям этой библиотеки применять importlib без потери информации. К сожалению, в случае сложных интерфейсов многие из исходных IDL-измов (IDL-ism) теряются в результирующей библиотеке типов, и тогда importlib не будет работать так, как хотелось бы. Грядущая версия компилятора MIDL, быть может, будет способна генерировать библиотеки типов, которые будут содержать все из исходного IDL.
Эмуляция классов
Часто случается, что разработчики классов желают развернуть новые версии уже существующих классов, чтобы исправить дефекты или расширить функциональные возможности. Полезно придать этим новым реализациям новые идентификаторы класса CLSID , чтобы клиенты могли четко различать, какая версия им нужна. В качестве примера посмотрим, что происходит, когда развертывается новая версия класса. Если для идентификации нового класса используется новый CLSID, (например, CLSID_Chimp2), то клиентам, определенно желающим использовать новую версию, следует использовать новый CLSID во время активации: // new client – новый клиент
IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:
// old client – старый клиент
IАре *рАре = 0;
hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Чтобы продолжать поддержку старых клиентов, разработчику Chimp необходимо сохранить в реестре исходный CLSID для удовлетворения этих запросов на активацию. Если изменилась семантика класса, то необходимо, чтобы исходный сервер также оставался доступным для этих клиентов. Однако бывает, что семантика просто расширяется. В этом случае предпочтительнее просто переадресовать запросы на активацию от старых клиентов на создание экземпляров нового класса.
Чтобы дать возможность разработчику новой версии класса прозрачно удовлетворять запросы на активацию для других CLSID , в СОМ введено понятие эмуляции классов (class emulation). Эмуляция классов позволяет разработчику компонента указать, что старый CLSID заменен новым, альтернативным CLSID, эмулирующим семантику исходного класса. Это позволяет прежним клиентам, делающим запросы на активацию с использованием прежнего CLSID, получать экземпляры нового усовершенствованного класса. Для индикации того, что у класса имеется новая альтернативная версия, в СОМ существует такая API-функция:
HRESULT CoTreatAsClass([in] REFCLSID rclsidOld, [in] REFCLSID rclsidNew);
Пусть Сhimp2 является новой версией класса Chimp, тогда следующий код проинформирует СОМ, что необходимо переадресовать запросы на активацию Chimp на запросы на активацию Chimp2:
// cause Chimp activation calls to activate Chimp2
// заставим запросы на активацию Chimp активизировать Chimp2
HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_Chimp2);
Эта API-функция добавляет следующий ключ реестра (registry key)
[HKCR\CLSID\{CLSID_Chimp}\TreatAs][1] @={CLSID_Chimp2}
Вызов CoTreatAsClass c CLSID_NULL в качестве второго параметра удаляет настройку TreatAs:
// cause Chimp activation calls to activate Chimps
// заставим запросы на активацию Chimp
// активизировать Chimps
HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_NULL);
Этот запрос восстанавливает исходную реализацию класса в состояние, предшествующее эмуляции. Клиенты могут запросить установку эмуляции данного класса, используя API-функцию CoGetTreatAsClass:
HRESULT CoGetTreatAsClass ([in] REFCLSID rclsidOld, [out] REFCLSID *pclsidNew);
Если запрошенный класс эмулируется другим классом, то CLSID эмулирующего класса будет возвращен посредством второго параметра и вся подпрограмма возвратит S_OK . Если же запрошенный класс не эмулируется другим классом, то посредством второго параметра будет возвращен исходный CLSID и подпрограмма возвратит S_FALSE. Необходимо также отметить, что в момент написания этой книги эмуляция классов не работает должным образом для удаленных запросов на активацию.
IАре *рАре = 0; hr = CoCreateInstance(CLSID_Chimp2, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Использование второго CLSID гарантирует, что клиенты не получат случайно старую версию класса Chimp . В то же время старые клиенты делают запросы на активацию с применением старого CLSID:
// old client – старый клиент
IАре *рАре = 0;
hr = CoCreateInstance(CLSID_Chimp, 0, CLSCTX_ALL, IID_Ape, (void**)&pApe);
Чтобы продолжать поддержку старых клиентов, разработчику Chimp необходимо сохранить в реестре исходный CLSID для удовлетворения этих запросов на активацию. Если изменилась семантика класса, то необходимо, чтобы исходный сервер также оставался доступным для этих клиентов. Однако бывает, что семантика просто расширяется. В этом случае предпочтительнее просто переадресовать запросы на активацию от старых клиентов на создание экземпляров нового класса.
Чтобы дать возможность разработчику новой версии класса прозрачно удовлетворять запросы на активацию для других CLSID , в СОМ введено понятие эмуляции классов (class emulation). Эмуляция классов позволяет разработчику компонента указать, что старый CLSID заменен новым, альтернативным CLSID, эмулирующим семантику исходного класса. Это позволяет прежним клиентам, делающим запросы на активацию с использованием прежнего CLSID, получать экземпляры нового усовершенствованного класса. Для индикации того, что у класса имеется новая альтернативная версия, в СОМ существует такая API-функция:
HRESULT CoTreatAsClass([in] REFCLSID rclsidOld, [in] REFCLSID rclsidNew);
Пусть Сhimp2 является новой версией класса Chimp, тогда следующий код проинформирует СОМ, что необходимо переадресовать запросы на активацию Chimp на запросы на активацию Chimp2:
// cause Chimp activation calls to activate Chimp2
// заставим запросы на активацию Chimp активизировать Chimp2
HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_Chimp2);
Эта API-функция добавляет следующий ключ реестра (registry key)
[HKCR\CLSID\{CLSID_Chimp}\TreatAs][1] @={CLSID_Chimp2}
Вызов CoTreatAsClass c CLSID_NULL в качестве второго параметра удаляет настройку TreatAs:
// cause Chimp activation calls to activate Chimps
// заставим запросы на активацию Chimp
// активизировать Chimps
HRESULT hr = CoTreatAsClass(CLSID_Chimp, CLSID_NULL);
Этот запрос восстанавливает исходную реализацию класса в состояние, предшествующее эмуляции. Клиенты могут запросить установку эмуляции данного класса, используя API-функцию CoGetTreatAsClass:
HRESULT CoGetTreatAsClass ([in] REFCLSID rclsidOld, [out] REFCLSID *pclsidNew);
Если запрошенный класс эмулируется другим классом, то CLSID эмулирующего класса будет возвращен посредством второго параметра и вся подпрограмма возвратит S_OK . Если же запрошенный класс не эмулируется другим классом, то посредством второго параметра будет возвращен исходный CLSID и подпрограмма возвратит S_FALSE. Необходимо также отметить, что в момент написания этой книги эмуляция классов не работает должным образом для удаленных запросов на активацию.
Категории компонентов
Как подчеркивалось в этой главе, основные примитивы активации СОМ требуют, чтобы вызывающей программе при создании новых экземпляров класса было известно его точное имя. Иногда, однако, бывает полезно просто потребовать, чтобы подходящим являлся любой класс, удовлетворяющий некоторым семантическим ограничениям. Кроме того, прежде чем сделать запрос на активацию, было бы полезно знать, какие сервисные средства класс требует от своих клиентов. В этом случае не будут создаваться объекты, которые клиент не готов должным образом поддерживать. Эти проблемы послужили причиной для создания категорий компонентов (component categories).