• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 910
  • Last Modified:

Not calling CloseHandle() on an ended thread HANDLE: is this a sin ?

Ah hello.

I create threads like this:

void CMyClass::CreateThread()
      //...other none-relevant stuff

      // First I make sure there is no thread already running in m_hThread, if there is, return (code not shown)

      CWinThread* pThread = AfxBeginThread(ThreadFunc, (LPVOID*)pThreadData, THREAD_PRIORITY_LOWEST,
            0, CREATE_SUSPENDED);

      ::DuplicateHandle (GetCurrentProcess (), pThread->m_hThread, GetCurrentProcess (), &m_hThread,

where m_hThread is a HANDLE member of CMyClass.  Now, according to Jeff Prosise's "Programming Windows with MFC" book, if I take this route to create a thread, I need to explicitly call ::CloseHandle(), passing the HANDLE to my thread.

I don't currently do this.

The thing is, I don't create my thread in a GUI, so to speak.  I have a standard class in a DLL that clients call.  The thread posts messages to any client GUI, if they provide the thread with a HWND (it is all standard stuff).  The only times I know that a thread is ended are

1) the client calls CMyClass::StopTask(), which stops the thread by setting an event that the thread periodically checks.  StopTask() then waits on the thread handle m_hThread

::WaitForSingleObject(m_hThread, INFINITE);
// If we get to here, we know the thread has fully ended...

2) The function ThreadFunc() reaching the end.

So, I know I can call ::CloseHandle() after ::WaitForSingleObject(m_hThread, INFINITE) has completed, but where can I call it when the thread finishes naturally ?  Could I call it at the end of ThreadFunc() ?  ( To do this, I would need to pass m_hThread to ThreadFunc(). )

It is worth noting that this code does not fail, even when creating thread after thread all in the same HANDLE m_hThread.  But still, I am not noticing any adverse effects from the absence of ::CloseHandle().  

Why do I need to call it then ?

  • 3
  • 2
1 Solution
Once your thread has finished its task it should inform the 'owner'.  So when the owner is informed you should be able to clean up the duplicate handle at that point.

Why use CloseHandle.  (AFAIK this is correct)  HANDLEs are a resource.  Not closing the handle will result in a resource leak.  On Win NT based systems it is less of a problem then Win95 based systems - those had a much smaller limit on the avaiable handles for the system.  Use the handles up and the OP system can grind to a halt/crash.
mrwad99Author Commented:
Hi Andy !

>> Once your thread has finished its task it should inform the 'owner'.

Yeah I know that.  Is what I suggested regarding passing the HANDLE to the thread function, and having the thread function call CloseHandle() just before returning ok or not ?

excerpt from help:
CloseHandle invalidates the specified object handle, decrements the object's handle count, and performs object retention checks. After the last handle to an object is closed, the object is removed from the system.

Closing a thread handle does not terminate the associated thread. To remove a thread object, you must terminate the thread, then close all handles to the thread.

I think you should be OK doing what you suggested, a HANDLE is not thread specific or anything like that.
mrwad99Author Commented:
Thanks Andy !

Any good with design patterns ? http:Q_21821996.html if you are :)
<Any good with design patterns ?>

I had a look at the question  the other day.  I'll have to check the link out before I can answer that question.  I have had little formal programming training - mostly self tought.   ;-)

Featured Post

Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now