Jump to content
  • Advertisement
Sign in to follow this  
Dookie

Creating Windows notifications from another thread...

This topic is 4018 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello! I'm playing around with multithreading some streaming audio code for my game, and my music loading code seems to be stopping here...
DSBPOSITIONNOTIFY theNotify[4];
...
theNotify[0].hEventNotify = CreateEvent(NULL,FALSE,FALSE,NULL);
The above code works perfectly if I call it directly from my mainloop (game's main thread), but if I call it from within a _beginthread() function then it doesn't work at all. I don't fully understand how multithreading works yet but I think what's happening is that this event is being created for the thread that was created by _beginthread(), but I don't know how to tell CreateEvent() that it actually wants to create events for the window handle "DXStuff->hWnd". Can anybody help me on this? Thanks in advance for the help!

Share this post


Link to post
Share on other sites
Advertisement
The events have nothing to do with windows. You should be checking the events are signalled with WaitForMultipleObjectsEx() (Or similar).

Share this post


Link to post
Share on other sites
Thanks for the reply, Evil Steve. You rock! [smile]

I'm using this to listen for handle events...
dwRet = WaitForMultipleObjects(4, DXStuff.hHandles, FALSE, 0);
if(dwRet == WAIT_TIMEOUT)
{
// Nothing to do
}
else if(dwRet == WAIT_FAILED)
{
// Should never happen
}
else
{
dwRet -= WAIT_OBJECT_0;
if(dwRet == 0)
{
// Stream audio data
}
...

This works fine if CreateEvent() is called from within my mainloop, but not if it's called from within _beginthread(). Would using WaitForMultipleObjectsEx() make a difference? Or should I be handling the above differently?

Share this post


Link to post
Share on other sites
That should be fine. Are you sure you're not closing the handle when it's being waited on by WaitForMultipleObjects? Or adding the handle to the list when it's in the middle of a wait (I've done both of those things before [smile])?
Closing the handle will cause WaitForMultipleObjects() to error out, and adding a new handle will cause the new handle to be ignored.

EDIT: Random snippet of code from my multithreaded DX audio thingy:

void PAudioThread::ThreadProc()
{
Assert(m_dwMainThreadId != GetCurrentThreadId(), "How is this the main thread?");

for(;;)
{
DWORD dwRet = WaitForMultipleObjects(m_dwNumHandles, m_hWaitableHandles, FALSE, INFINITE);
if(dwRet == WAIT_TIMEOUT)
continue;
else
{
Assert(dwRet != WAIT_FAILED, "Wait failed! GetLastError() = %d", GetLastError());
DWORD dwHandle = dwRet - WAIT_OBJECT_0;

// Was the thread signal handle signalled?
if(dwHandle == 0)
{
// Process message queue
if(!ProcessThreadMessages())
break;
}
else
{
EnterCriticalSection(&m_cs);
{
// Find the buffer associated with this handle and notify it
HandleMapIter it = m_mapHandles.find(m_hWaitableHandles[dwHandle]);
Assert(it != m_mapHandles.end(), "Handle not found!");
it->second->OnNotify(m_hWaitableHandles[dwHandle]);
}
LeaveCriticalSection(&m_cs);
}
}
}

Assert(m_dwNumHandles == 1, "Handles still active!");
}


Effectively, the thread also handles notifications that it should wake up and add / remove handles from it's wait list. That way you don't go and touch the handle array while it's in the middle of doing something.

Share this post


Link to post
Share on other sites
Wow, your handle-friendly code is pretty awesome!

I bet you're right, in that I'm probably closing handles while they're being used... Thanks for pointing me in a direction, I'll play around with my code and see if I can get somewhere with it. I'll later post how it went and let you know whether I finally got it working.

Thanks again! [smile]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!