Maarten Lankhorst schrieb: > Peter Beutner schreef: >> But this only works if DSOUND_Stop and DSOUND_Release are called from >> different threads, right? > It is during shutdown, DSOUND has an internal timer/thread called the > mixer, it calls DSOUND_Stop because we signalled it to stop playbacking, > then the program calls idirectsoundbuffer_release which calls > DSOUND_Release. Since DSOUND_release also unsets hwbuf, the timer would > then continue to use an uninitialized waveout interface, which could > result in something even uglier. >> Isn't the real problem that when ALSA_DestroyRingMessage(*) is called from >> IDsDriverBuffer_Release it doesn't check if there are still any "fast >> messages" >> in the queue which wait for their message to be handled? >> Just from a quick look it seems you could theoretically trigger the >> same deadlock with the WODM_RESET & WODM_CLOSE messages when using >> the waveout system. > I agree it's horribly complex, I hope to improve that in alsa during > summer. That's great ;)
> However when calling IDsDriverbuffer_Release dsound says it no > longer has anything that uses that interface. Because > IDsDriverBuffer_Stop hasn't returned yet this is in fact untrue: it is > still using idsdriverbuffer, so to make sure it isn't, dsound has to > hold the mixer lock so it waits until the mixer is done playing around. > > You are _NOT_ allowed to call Release on a interface if you still have > something that uses the interface. The bug is definitely in dsound, it > just resulted in winealsa being unresponsive. ok that makes sense. Definitely something wrong in dsound. But I still think that ALSA_DestroyRingMessage should signal any message left in the queue. Imo it just calls for trouble to expect that messages always are added in the right order.
