Prev: RPC Service Interface Registration in target Session Space
Next: createfile's flags for DVD drive
From: tfs on 26 Jun 2010 13:19
In my MFC extended dll, during DLL_PROCESS_DETACH I add a clean-up function
to exit all worker-threads (created by AfxBeginThread(ThreadProc)). But if I
use WaitForSingleObject() to wait for the BG-thread to exit,
WaitForSingleObject() never returns:

e.g.

CWinThread* pBGThread = < previously created by AfxBeginThread(ThreadProc,
....); >

HANDLE hThx = pBGThread->m_hThread;
// signal the ThreadProc() to exit
::WaitForSingleObject(hThx, INFINITE); // never returns, even though I've
debug-traced that ThreadProc() had already exited


However, if I use ::GetExitCodeThread() instead of ::WaitForSingleObject():

DWORD dwExitCode = 0;
while (::GetExitCodeThread(hThx, &dwExitCode)) {
if (dwExitCode != STILL_ACTIVE) break;
::Sleep(10);
dwExitCode = 0;
}

at least it doesn't hang forever, but that is because ::GetExitCodeThread()
returns FALSE, and I do not have the required thread exit-code retrieved (I
deliberately put return 100 in ThreadProc(), but dwExitCode is 0).

Are the above problems simply because when the dll is in DLL_PROCESS_DETACH
state?

From: Leo Davidson on 26 Jun 2010 18:27
On Jun 26, 6:19 pm, tfs <t...(a)discussions.microsoft.com> wrote:

> Are the above problems simply because when the dll is in DLL_PROCESS_DETACH
> state?

Yes. It's wrong to do anything like that in DllMain, as per MSDN.

After reading MSDN (which is pretty vague beyond saying, basically,
"don't do anything much in DllMain"), read through all the OldNewThing
articles mentioning DllMain to learn some more.

Type this into google to find them:

site:blogs.msdn.com dllmain oldnewthing
 | 
Pages: 1
Prev: RPC Service Interface Registration in target Session Space
Next: createfile's flags for DVD drive