Re: returning from worker thread
That's very helpful, Scott. Between our posts, I had tried tried a while
loop with SuspendThread. For my simple waveOut, it seems to be working just
fine. Is there anything fundamentally wrong with this approach? Mainly, I
am trying to get a firm grasp on such use of a thread. Also, if you get the
time, would you mind demonstrating a version that relies on messaging? I
want to be sure to get what you're saying about that, and these examples
together might just be the best way for me to see the picture most clearly.
Thanks again!
// audio thread function
UINT AudioThreadFunc(LPVOID pParam)
{
while(TRUE)
{
CAudioFile* audiofile = (CAudioFile*)pParam;
if(WaitForSingleObject(audiofile->m_hndDone,INFINITE) != WAIT_OBJECT_0)
{
// error handling code goes here
return 0;
}
CloseHandle(audiofile->m_hndDone);
if(audiofile->m_pView->m_hWnd)
audiofile->m_pView->PostMessage(WM_AUDIO_CLEANUP);
else
audiofile->CleanUp();
::SuspendThread(audiofile->m_pAudioThread->m_hThread);
}
return 0;
}
----------------------
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:uC8fsvbvGHA.1808@TK2MSFTNGP06.phx.gbl...
Steve Russell wrote:
// first call for thread
if(!m_pAudioThread)
{
m_pAudioThread = AfxBeginThread(AudioCallback, this, 0, 0,
CREATE_SUSPENDED);
m_pAudioThread->m_bAutoDelete = false;
m_pAudioThread->ResumeThread();
}
. . .
if(waveOutWrite(m_hWaveOut, m_WaveHdr, sizeof(WAVEHDR)))
. . .
How do I make subsequent calls to the worker thread's function, i.e.
AudioCallback?
To keep the thread alive for the life of the app the thread is going to be
started one time only and consist of a "do forever" loop.
You don't "call" a thread, you signal to it. You can use a worker thread
or a message-driven thread. For the worker thread case like you have now
the new thread function would look about like this...
UINT AudioCallback(LPVOID param)
{ CSomeClass* p = (CSomeClass*)param;
while(TRUE)
{ DWORD signal = WaitForMultipleObjects(
p->hcount, p->handles, FALSE, INFINITE);
switch(signal)
{ case ... break;
case ... break;
}
}
return 0;
}
While no event is signaled the thread is suspended in
WaitForMultipleObjects. You signal to the thread using SetEvent, which
causes one of the case statements to execute. The first case should be a
shutdown command that makes the thread exit during app shutdown.
A message-driven thread is better in many cases, but since you already
have a worker thread I guessed you probably want to try this approach.
I suggest you change the name of the thread function - callback is
misleading.
--
Scott McPhillips [VC++ MVP]