Question on CloseHandle and Threads

[Abubakar]

Hi,

from msdn: "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."

Through the documentation it seems that the thread proc must be exited
*first* and than the CloseHandle should be called on its handle. My problem
is that my threads will exit whenever they want without notifying any other
part of my code. So who will take care of closing their handles? For this
reason I have written the code in such a way that the threads close their
own handle just before they r about to exit from their thread proc. For
example here is what my code looks like.
class anyclass
{
//some where up here is HANDLE m_threadhandle; which contains a valid thread
handle
......
anyclass::thread_proc()
{
// thread functionality here

...

// on the last line before exiting:
CloseHandle( m_threadhandle );
}
}
Is this ok?

Regards,

Ab.

 

[adebaene]

Abubakar a écrit :

Hi,

from msdn: "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."

Through the documentation it seems that the thread proc must be exited
*first* and than the CloseHandle should be called on its handle.

No : a thread is destroyed when it has exited it's thread proc AND all
it's handles are closed. The order in which those events occurs is
irrelevant.

My problem
is that my threads will exit whenever they want without notifying any other
part of my code. So who will take care of closing their handles?

The only reason you may want to keep the handle on a newly created
thread is precisely if you want to wait for this thread to exit (or
manipulate the thread one way or antoher : suspend it, set it's
priority, etc..., but those are usually reserved for debuggers).

If none of your code ever wait for the thread to exit, you can close
the handle returned by CreateThread (or whatever function you use)
immediatly after the CreateThread' call.

For this
reason I have written the code in such a way that the threads close their
own handle just before they r about to exit from their thread proc. For
example here is what my code looks like.
class anyclass
{
//some where up here is HANDLE m_threadhandle; which contains a valid thread
handle
.....
anyclass::thread_proc()
{
// thread functionality here

...

// on the last line before exiting:
CloseHandle( m_threadhandle );
}
}
Is this ok?

It is ok but you do not need to make things so complicated...

Arnaud
MVP - VC

 

[Doug Harrison [MVP]]

Hi,

from msdn: "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."

Through the documentation it seems that the thread proc must be exited
*first* and than the CloseHandle should be called on its handle. My problem
is that my threads will exit whenever they want without notifying any other
part of my code. So who will take care of closing their handles? For this
reason I have written the code in such a way that the threads close their
own handle just before they r about to exit from their thread proc. For
example here is what my code looks like.
class anyclass
{
//some where up here is HANDLE m_threadhandle; which contains a valid thread
handle
.....
anyclass::thread_proc()
{
// thread functionality here

...

// on the last line before exiting:
CloseHandle( m_threadhandle );
}
}
Is this ok?

This is essentially what MFC's CWinThread does. Is it a good idea? No. If
the threads die without notifying anyone, it follows that the program can
terminate while they're still running. You should avoid that for reasons
given here in Q1 and Q2:

http://members.cox.net/doug_web/threads.htm

 

[Abubakar]

Thanks guys for the answers.

Ab.

This is essentially what MFC's CWinThread does. Is it a good idea? No. If
the threads die without notifying anyone, it follows that the program can
terminate while they're still running. You should avoid that for reasons
given here in Q1 and Q2:

http://members.cox.net/doug_web/threads.htm