Hi Sean, Using CreateThread and EndThread can result in memory leaks if you then go on to call some of the CRT functions. This is because some of the CRT functions use global variables, such as errno, or allocate static buffers, and these have one copy per thread to prevent race conditions. If you create a thread using CreateThread and terminate it using EnThread then these per thread global variables and static buffers won't be freed by the CRT when the thread exits. So, to avoid a memory leak you need to use the CRT functions to create and end threads such as _beginthread and _endthread or _beginthreadex and _endthreadex. It's also worth noting that you don't need to manually end a thread by calling something like _endthread. The thread will terminate by itself when its start function exits. WaitForMultipleObjects returns a DWORD value that represents the event that was signalled. Under some circumstances it can return other values to indicate other things, and the MSDN Library entry for WaitForMultipleObjects explains what these are. Will ----- Original Message ----- From: Sean Farrow To: programmingblind@xxxxxxxxxxxxx Sent: Sunday, December 30, 2007 2:24 PM Subject: RE: [BULK] Re: Exiting threads safely Hi Will: What are the benefits of using BeginTgheadEx over the standard thread proc, wich is what I am usin at the moment? And What does WaitForMultipleObjects return? Sean. ------------------------------------------------------------------------------ From: programmingblind-bounce@xxxxxxxxxxxxx [mailto:programmingblind-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson Sent: 30 December 2007 14:16 To: programmingblind@xxxxxxxxxxxxx Subject: [BULK] Re: Exiting threads safely Importance: Low Hi Sean, I think that using a process finding mechanism might result in a race condition. The main thread for the application, and thus the application itself, might terminate before your process finding mechanism has had a chance to run. Using multiple WaitForSingleObjects also has its problems. A thread might nnot be waiting on the object that signals process shutdown. If the other event isn't signalled to free the thread then the thread won't get an opportunity to wait on the event that does signal process shutdown, and the thread will be forceably terminated when the application terminates without processing the termination event. If you want a clean termination of the thread then WaitForMultipleObjects will probably provide the best chance of getting it. The way I've used WaitForMultipleObjects to accomplish this in the past is to have one of the events indicate that the thread should terminate. I then use a while loop, just as you have done, and process the event ID, which is the value returned by WaitForMultipleObjects, using a switch statement. If the event that signalled the thread indicates that the thread should terminate then the appropriate case in the switch statement sets the bool value used for the while loop to either true or false, depending on which one I've used to exit the while loop. So, the code looks something like: while (Run == TRUE) { Event = WaitForMultipleObjects(2, hFoo, FALSE, INFINITE); switch (Event) { case 0: Run = FALSE; break; case 1: // do something break; } // switch } // while In the above example I've placed the event that signals the termination of the thread at array index 0 of the array containing the wait handles. WaitForMultipleObjects will return the lowest numbered event as the return value if multiple events are signalled at the same time. Placing the termination event at array index 0 ensures that the termination event will always be returned if it is signalled and that the loop will exit when it is signalled. Using WaitForMultipleObjects doesn't completely eliminate the possibility that the process can terminate without your thread receiving the termination signal but it does reduce the possibility that this could happen compared to using two WaitForSingleObject calls. If your thread is doing some work and not waiting on an event then there is still the possibility that the application's main thread could exit before your thread processes the termination signal. If you want your thread to cleanly terminate before the process terminates because you need to do some clean up or something then you need to serialise the execution. The way I usually go about this is to have the application's main thread wait on an event until the other thread has done its clean up or whatever work it has to do. Just before the thread exits, usually just before the end of the function that I passed in as the starting function to a call to _beginthreadex, I set the event that the application's main thread is waiting on to signelled. This serialises execution and ensures that the clean up code or whatever work I want done will be done before the process terminates. Will ----- Original Message ----- From: Sean Farrow To: programmingblind@xxxxxxxxxxxxx Sent: Sunday, December 30, 2007 11:49 AM Subject: Exiting threads safely Hi list: I am in a situation wher i am creating threads in a com server. The threads use WaitForSingleObject to process cross process communication. I need to exit these two created threads when --and only when an application exits. is the safest way to do thi using a process finding mechanism (I aleady have this in place anyway) or using a second event. If the latter, can I use this in a while lop like the following: while(WaitForSingleObject(hevent, infinite) !=0) { code if the thread isn't to exit--i.e wait on the first event. } exit the thread using an ExitThread call. Any help apreciated. Sean.