При разработке dll приходится мириться с тем фактом, что как правило программы прекращают свое существование, используя для этого вызов функции ExitProcess. Причем многие из них могут вызывать эту функцию в тот момент, когда ваша dll еще загружена.
Функция ExitProcess, в свою очередь, известна тем, что сначала останавливает все потоки, кроме вызывающего (используя NtTerminateProcess), а потом вызывает EntryPoint для всех dll с флагом DLL_PROCESS_DETACH. В С++ обычно точка входа называется DllMainCRTStartup. DllMainCRTStartup вызывает функцию DllMain и после нее все деструкторы глобальных объектов, расположенных в DLL.
Разумеется, что после удаления некоторого количества потоков, отличного от нуля, выполнение любого кода становится чрезвычайно опасным мероприятием, чреватым дедлоками и крешами. Некоторые комрады также утверждают, что после вызова ExitProcess перестают работать критические секции, и случаются многие другие
Ужасные Вещи.
Поэтому, популярный паттерн использования DLL_PROCESS_DETACH выглядит так:
BOOL WINAPI DllMain(
IN HINSTANCE hinstDll,
IN DWORDfdwReason,
LPVOID lpvReserved
)
{
....
case DLL_PROCESS_DETACH:
if( lpvReserved == NULL )
{
// FreeLibrary is called and it is safe to free resources
// All critical sections and other primitives should work fine
FreeResources1();
FreeResources2();
...
FreeResourcesN();
}
// else { ExitProcess is called, process is terminating, so do nothing }
break;
} |
| _Winnie C++ Colorizer |
Параметр lpvReserved описан в MSDN следующим образом:
If fdwReason is DLL_PROCESS_DETACH, lpvReserved is NULL if FreeLibrary has been called or the DLL load failed and non-NULL if the process is terminating.
(с) MSDN
В случае использования С++, код нашей идеальной Dll должен выглядеть так:
static std::auto_ptr<CMyDll> g_myDll;
BOOL WINAPI DllMain(
IN HINSTANCE hinstDll,
IN DWORD fdwReason,
LPVOID lpvReserved
)
{
....
case DLL_PROCESS_DETACH:
if( lpvReserved == NULL )
{
g_myDll.reset(0);
}
g_myDll.release();
break;
} |
| _Winnie C++ Colorizer |
В приведенном коде нет особых проблем, но нельзя упускать тот факт, что наша идеальная dll может подключать и, как правило, подключает множество статических библиотек. Которые вполне могут содержать глобальные переменные-объекты.
Выводы крайне тривиальны: использование глобальных переменных-объектов - есть зло, особенно в статических библиотеках. Но если вы уже разрабатываете статическую библиотеку на С++ с глобальными переменными внутри, стоит предоставить функцию для их корректного фатального освобождения, с семантикой, аналогичной g_myDll.release().
