Alsa-lib 'cancelability'

Alsa-lib 'cancelability'

[Alan Horstmann]

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

Re: Alsa-lib 'cancelability'

[Clemens Ladisch]

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

Re: Alsa-lib 'cancelability'

[Alan Horstmann]

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