[alsa-devel] Deadlock over semaphore issue with aplay while using dmix
perex at perex.cz
Thu Apr 4 13:33:08 CEST 2013
Date 4.4.2013 11:27, mateen wrote:
> I seeing sometimes deadlock issue with dmix when I press CTRL+C.
> Aplay's signal handler calls snd_pcm_close() if an interrupt occurs.
> snd_pcm_close() will internally call pcm->ops->close() which will fall to
> snd_pcm_dmix_close() in case you are using dmix.
> snd_pcm_dmix_close() will try to acquire the semaphore with
> snd_pcm_direct_semaphore_down(dmix, DIRECT_IPC_SEM_CLIENT).
> The same semaphore is acquired in snd_pcm_dmix_sync_area() with
> dmix_down_sem() in case of non-concurrent access.
> If semaphore is acquired in snd_pcm_dmix_sync_area() which is in thread
> context and interrupt comes, which invokes the signal handler which is in
> ISR context, which calls snd_pcm_close() which in turn calls
> snd_pcm_dmix_close() then we see a deadlock since semaphore is not released
> from thread context and ISR is waiting indefinitely on the same semaphore.
> Please suggest a suitable solution for this.
It seems that also other configurations (alsa-lib plugins) have trouble
with the closing from the signal handler - I hit mutex issues with the
PulseAudio plugin, too.
The question is, how we can do a clean path in this case. Looking to the
current alsa-lib code, I would suggest to add the snd_pcm_abort()
function (may be called from the interrupt handler) to notify the
library to not ignore -EINTR return codes from poll() and other i/o ops
and pass it to the caller (application) to finish the normal close sequence.
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.
More information about the Alsa-devel