Continuing in my efforts to get MOD4WIN working, I have come across the
following problem. Its a 16bit application and it calls waveOutReset
while holding the Win16Mutex (SysLevel 1). Wine attempts to send a
notify message back about this. However, the notify gets sent from a
different thread. That thread needs to send the notify to 16bit code
and thus needs to obtain the lock. The original thread is still holding
the lock and is waiting for the other thread to finish sending the
notify before continuing.
The following patch removes the problem for me. I just arbitrarily
stuck a ReleaseThunkLock/RestoreThunkLock around the wait call in the
first thread. Is this the right solution and the correct place to put
it? If so, do the other similar functions there need the same thing?
--
James Abbatiello
Index: dlls/winmm/wineoss/audio.c
===================================================================
RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v
retrieving revision 1.20
diff -u -r1.20 audio.c
--- dlls/winmm/wineoss/audio.c 2000/07/26 18:07:06 1.20
+++ dlls/winmm/wineoss/audio.c 2000/08/19 03:19:30
@@ -39,6 +39,7 @@
#include "heap.h"
#include "ldt.h"
#include "debugtools.h"
+#include "syslevel.h"
DEFAULT_DEBUG_CHANNEL(wave);
@@ -960,6 +961,7 @@
*/
static DWORD wodReset(WORD wDevID)
{
+ DWORD level;
TRACE("(%u);\n", wDevID);
if (wDevID >= MAX_WAVEOUTDRV || WOutDev[wDevID].unixdev == 0) {
@@ -969,7 +971,9 @@
TRACE("imhere[3-RESET]\n");
PostThreadMessageA(WOutDev[wDevID].dwThreadID, WINE_WM_RESETTING, 0, 0);
+ ReleaseThunkLock(&level);
WaitForSingleObject(WOutDev[wDevID].hEvent, INFINITE);
+ RestoreThunkLock(level);
return MMSYSERR_NOERROR;
}
