Re: Can CWinThread::SuspendThread suspend yourself?
See below:
"Norman Diamond" <ndiamond@community.nospam> wrote in message
news:%23knV8LeYHHA.3824@TK2MSFTNGP02.phx.gbl...
I'm not sure if this is a generic coding bug (e.g. buffer overflow
somewhere), a violation of a Win32 constraint on SuspendThread, a
violation
of an MFC constraint on CWinThread::SuspendThread, or a bug in Visual
Studio
2005's version of MFC or in Windows XP or where.
CWinThread *T = AfxBeginThread(f, p);
And "T" goes out of scope, and is destroyed, when the function that does
this returns.
UINT f(LPVOID p) {
// do some stuff
T->SuspendThread();
// when someone resumes us, we continue
}
You need to make "T" persistent; a global variable or class member might be
appropriate. Elsewise, the "T" pointer sometimes will be valid, and
sometimes won't, depending on the timing between exit of the afore-mentioned
function and execution of the SuspendThread() call.
Incidentally, it's perfectly valid for a thread to suspend itself. In fact,
it might be the only valid use for this function.
Running in debug mode under control of Visual Studio 2005, about 66% of
the
time this runs silently, but about 33% of the time it gets an exception on
an assert in afxwin2.inl, which makes no sense to me. It seems that
m_hThread is non-NULL as it should be, and the assert complains that a
memory read failed at a highly suspicious memory address. The memory
address varies but is always a very small multiple of 4, looking very
suspiciously like a handle value not a memory address, making me wonder
who's trying to read memory there.
While typing this message I observed that __cdecl is missing from the
declaration of f. But Visual Studio 2005 didn't issue any error message
about the call to AfxBeginThread. I don't think I know the real problem
yet.