told me. Including the following in my audio class destructor, about which
I do want that thread pointer, so let's don't tackle that subject, please.
And it is good from start to finish in my program. But in the destructor, I
thread had finished .
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
Leaving a thread alive is easy: don't kill it. Thread creation can be
expensive, so if
you want responsiveness, putting thread creation in the critical path will
hurt you.
What I did was create a simple UI thread, which runs until I ask it to
shut down. I post
a WM_QUIT message to it to shut it down. The rest of the time, it mostly
waits on a
GetMessage call deep in CCmdTarget::Run waiting for something to happen.
When I want it
to make a sound, I do a PostMessage to it, where the LPARAM and WPARAM
contain the
information about what I want the sound to be. So the thread wakes up as
nearly instantly
as Windows typically manages, invokes the snd APIs to make the sound, and
goes back to its
wait state.
See below...
On Fri, 11 Aug 2006 19:58:02 -0400, "Steve Russell"
<srussell@removethisinnernet.net>
wrote:
I find myself puzzled as to how to leave the worker thread alive. In a
function that I call AudioWaveOut, I had been including this:
. . .
if(m_pAudioThread)
{
delete m_pAudioThread;
m_pAudioThread = NULL;
}
m_pAudioThread = AfxBeginThread(AudioCallback, this, 0, 0,
CREATE_SUSPENDED);
m_pAudioThread->m_bAutoDelete = false;
m_pAudioThread->ResumeThread();
*****
Actually, you only need to do this once. Once for your entire execution.
*****
. . .
if(waveOutWrite(m_hWaveOut, m_WaveHdr, sizeof(WAVEHDR)))
. . .
Now, in an attempt to implement what you are saying, I am trying this:
. . .
// 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?
****
You wouldn't, and you don't need to. Your thread implements a "server" or
"consumer". How
you queue up requests to that consumer is up to you. For a UI thread, the
message pump
forms the queue, and this works as long as you don't have a lot of things
to queue up and
a single server is sufficient. Otherwise, you can look at my essay on
semaphores on my
MVP Tips site and "roll your own" queueing mechanism, or use an I/O
Completion Port and
just have your server thread sit on a GetQueuedCompletionStatus call, see
my essay on the
use of I/O Completion Ports.
*****
----------------
"Scott McPhillips [MVP]" <org-dot-mvps-at-scottmcp> wrote in message
news:edc2zSOvGHA.5056@TK2MSFTNGP06.phx.gbl...
Steve Russell wrote:
Let me stick with one specific example for now: A 2-second audio clip
is
playing. The student quickly drags and drops a sprite before the audio
is finished playing. The underlying code for that operation performs
many functions, including setting a timer to check that the audio has
concluded before going on with further considerations that include
audio
cleanup and beginning the next loop.
1 audio != 1 thread
If you have tightly linked playing one audio clip with creating and
shutting down one thread then you have unnecessary complexity, which
sounds like overhead that's getting in your way. Imagine an audio
thread
that exists for the lifetime of the app. When you want it to play
something you post it a message telling it what to do. Then you forget
about it. Or, if you really need to know if/when the clip has finished
the thread posts a message to you when that happens. But the thread
remains ready, waiting for the next command message.
--
Scott McPhillips [VC++ MVP]
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm