Peter Beutner schreef: > AFAIK you get the DRVM_EXIT message only when winmm is unloading. > Alternatively you could do it in response to the DRV_CLOSE message which winmm > sends just before it tries to unload the driver. > > That said I don't see how your code in ALSA_MixerExit() could deadlock. > It effectively tries to exit the thread the same way as MIX_Close, doesn't it? > So the thread should exit safely. > Imo the question is rather why the thread isn't exiting and you are waiting > forever. Forcibly calling TerminateThread just covers the problem The deadlock isn't in the alsa code, it's in the kernel code: Kernel holds thread lock and calls closing winmm code, closing code closes mixer driver, mixer closing waits on thread, thread waits till it can hold thread lock -> deadlock.
Under normal circumstances, MIX_Open will be called as often as MIX_Close is. If the programmer is lazy and never closes its handle, MIX_Close will be called when winmm is shutting down, in that case I would want to pass some kind of signal that it can't wait on thread exit because it would deadlock. The thread should still be terminated in MIX_Close then, so unless you pass a flag that application hasn't shut down the device driver properly, this potentially causes the deadlock to occur. The thread termination in ALSA_MixerExit should never happen: it would indicate a bug in winmm that it doesn't close mixer before releasing it, but I put it in as a safeguard, that's why it will print an ERR too. Maarten
