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