dsound: Make sure we're holding the lock on Drop And Stop , try 2

[Peter Beutner]

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.