DSBPOSITIONNOTIFY theNotify[4];
...
theNotify[0].hEventNotify = CreateEvent(NULL,FALSE,FALSE,NULL);Creating Windows notifications from another thread...
Author
Hello!
I'm playing around with multithreading some streaming audio code for my game, and my music loading code seems to be stopping here...
The events have nothing to do with windows. You should be checking the events are signalled with WaitForMultipleObjectsEx() (Or similar).
Author
Thanks for the reply, Evil Steve. You rock! [smile]
I'm using this to listen for handle events...
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?
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?
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:
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.
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.
Author
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]
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]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement