Ending classes with threads and callbacks

[Gyannea]

I have had ongoing problems when trying to terminate an instance of a class that contains
(1) dialog callbacks or windows callbacks and
(2) threads

The trouble seems to be mostly making sure that the thread terminates before the class is "deleted". I have tried all kinds of approaches from placing my own class globals inside of the thread, using "WaitOnSingleObject()", saving the "delete this" expression to WM_NCDESTROY in the callback, etc.

For a while everything seems to work and then when things are changed around it fails.

Is there any proper technique that can terminate the thread, terminate the callback procedure, and then delete the instance of the class...making sure that it happens in that order?

Also, I often have these problems when using the debug mode. The problems go away in the release mode. Never been able to figure that one out.

Thanks,

Brian

[NoHero]

Posting code would help us to see what you are doing ...
But doing "TerminateThread()" and those things in the destructor of the class, does not solve the problem?

[Gyannea]

I have heard bad things about those routines and that the safest way is to try to get the thread to self-terminate (return).

The problem is that in a class you have static functions which call class-instance functions for threads and window or dialog procedures. When you start ending these functions (DestroyWindow) and getting the thread to terminate its hard to know when they are 'terminated enough' to destroy the class.

I have several instances of this situation and all of them have suffered from these problems at one time or another. I keep trying different orders till things seem to behave correctly.

I usually try to first end the window procedure with a DestroyWindow(). In the WM_DESTROY message I Signal the thread to end by triggering a wait object. Then I often wait on an indicator like "while(hthreadevent != NULL)" to make sure the thread has ended, but sometimes this seems to cause a system lock so I hate to include it. In the WM_NCDESTROY message I finally do the "delete this" to kill the object. That was an idea I got from this forum. Of course the thread runs in its own time slice, so you could get to the "delete this" before the thread terminates.

I am just looking for a suggestion of how to order the destruction of a class that contains a window or dialog procedure and a thread (with an infinite loop). I wonder what kind of subtle problems come up because one has to branch out to instance versions of both the callback functions and threads.

Brian

[NoHero]

Did I catch this right you have a thread with an infinite loop and you pass a this member through the thread procedure?!

I would solve it this way


DWORD CMyThread::ThreadProc ( LPVOID Param )
{
CMyThread *ptr = (CMyThread*)Param;

while ( !Param.m_bEndThread )
{
// do loop
}
return 0;
}


But you have to pass "this" through your thread procedure. So you can set the private boolean member "m_bEndThread" to true and the thread will check this an terminate on its own. Does this help a bit?

[Gyannea]

Its the other way around.

I have a thread that is created after a class is created...

Actually the class is created using "new",
The class is then initialized and during initialization,
a dialog box is created (and thus a dialog procedure callback function which is static and then must call the instance procedure)
A thread is created (which is static and thus calls the instance "thread" and the latter is an infinite loop). The thread has a WaitForSingleObject() on 'hevent' which is class global. When a second class global 'txcycle' is set and the wait function signalled, the thread is supposed to return.

To kill the class I
call DestroyWindow() by using a button push in the classical manner,
in the WM_DESTROY message I call SignalEvent(hevent) after setting 'txcycle'
in the WM_NCDESTROY message I "delete this"

I pray that all reminents of the thread, procedure, and class are gone.

I don't know if my prayers are answered.

I do this in many different cases not knowing any better way to do it.

Brian