[alsa-devel] Alsa-lib 'cancelability'
Hi,
I am wondering if there is a policy on the thread 'cancelability' / 'cancellability' of the functions in Alsa-lib?
We are dissecting an issue on the Portaudio list which has appeared with the 'Locking API' version 1.1.2, when using the Portaudio callback API. The callback runs in it's own thread; when a user requests 'AbortStream' a thread cancel is requested. Sometimes it seems this can take effect during snd_pcm_mmap_commit(), so the function never completes and a lock is not released. Then, during the cleanup, snd_pcm_drop() attempts to aquire the lock, which is already held, and a lock-up occurs.
Is it up to the application to ensure each Alsa function completes, eg by disabling cancelability on the thread for those periods, or is it reasonable to expect the functions to ensure they complete adequately?
Any comment would be appreciated.
Regards
Alan
Alan Horstmann wrote:
I am wondering if there is a policy on the thread 'cancelability' / 'cancellability' of the functions in Alsa-lib?
Yes. The policy is "don't even think about it".
The callback runs in it's own thread; when a user requests 'AbortStream' a thread cancel is requested.
Alsa-lib is not the only library with this 'policy'. You cannot cancel threads over whose code you do not have complete control.
Regards, Clemens
Hi Clemens,
I missed replying to say thanks for the quick response - appreciated.
On Monday 22 August 2016 18:37, you wrote:
Alan Horstmann wrote:
I am wondering if there is a policy on the thread 'cancelability' / 'cancellability' of the functions in Alsa-lib?
Yes. The policy is "don't even think about it".
Too late - it's been happening for years!
The callback runs in it's own thread; when a user requests 'AbortStream' a thread cancel is requested.
Alsa-lib is not the only library with this 'policy'. You cannot cancel threads over whose code you do not have complete control.
I was unsure whether libraries might disable cancelablility themselves as a defensive measure so as to protect the internal states - in this case to prevent the audio system from getting 'screwed-up', if only for other users.
We will have to ensure there is only limited opportunity for cancelling the thread during well-chosen sections. Initial patches to do just that are proving effective.
Thanks again,
Alan
participants (2)
-
Alan Horstmann
-
Clemens Ladisch