2009. 9. 14. 08:44
DLL Main과 Class 생성자, 파괴자의 호출 순서
2009. 9. 14. 08:44 in 프로그래밍/Win32
DLL이 로드될때, DLLMain(...)이 호출되는데,
만약, 전역 변수로 된 class instance가 있는 경우,
DLLMain과 생성자/파괴자의 호출순서는 다음과 같습니다.
// TestApp.dll
DLLMain(...)
{
...
}
CApp g_theApp;
1) LoadLibrary(TestApp.dll)
2) g_theApp에 의한 CApp 생성자
3) DLLMain(...)의 DLL_PROCESS_ATTACH
4) ...
5) FreeLibrary(Module Handle of TestApp.dll)
6) DLLMain(...)의 DLL_PROCESS_DETACH
7) g_theApp에 의한 CApp 파괴자
와 같습니다.
전역 theApp등은 MFC에서 CApp class를 위해 응용되는 기술이죠.
DLL 개발시 되도록이면, DLLMain(...)에 코드 삽입을 피하는것이 좋습니다.
만약, 3)의 코드에서 Sleep(무한대)를 넣어버리면, LoadLibrary(...)를 호출한 caller는
pending 되어 버립니다. 또한 LoadLibrary(...)에서 사용되는 CRITICAL_SECTION Locking에
의한 deadlock이 발생이 가능해 집니다.
만약, 전역 변수로 된 class instance가 있는 경우,
DLLMain과 생성자/파괴자의 호출순서는 다음과 같습니다.
// TestApp.dll
DLLMain(...)
{
...
}
CApp g_theApp;
1) LoadLibrary(TestApp.dll)
2) g_theApp에 의한 CApp 생성자
3) DLLMain(...)의 DLL_PROCESS_ATTACH
4) ...
5) FreeLibrary(Module Handle of TestApp.dll)
6) DLLMain(...)의 DLL_PROCESS_DETACH
7) g_theApp에 의한 CApp 파괴자
와 같습니다.
전역 theApp등은 MFC에서 CApp class를 위해 응용되는 기술이죠.
DLL 개발시 되도록이면, DLLMain(...)에 코드 삽입을 피하는것이 좋습니다.
만약, 3)의 코드에서 Sleep(무한대)를 넣어버리면, LoadLibrary(...)를 호출한 caller는
pending 되어 버립니다. 또한 LoadLibrary(...)에서 사용되는 CRITICAL_SECTION Locking에
의한 deadlock이 발생이 가능해 집니다.
'프로그래밍 > Win32' 카테고리의 다른 글
Vista에서 Crash Dump 파일 만들기 (0) | 2009.10.06 |
---|---|
non-MFC에서 손쉽게 Memory Leak 발견하고 해결하기 (0) | 2009.09.24 |
.exe에 Manifest 추가 (0) | 2009.09.22 |
MAX_PATH가 넘어가는 Path 생성하기 (0) | 2009.09.14 |
GetShortPathName(...)의 함정 (0) | 2009.09.14 |