On Tue, 30 Aug 2016 17:54:22 +0200, Alan Horstmann wrote:
On Tuesday 30 August 2016 15:20, Takashi Iwai wrote:
(Adding Alan to Cc)
On Fri, 26 Aug 2016 21:02:12 +0200,
Samuel Thibault wrote:
Samuel Thibault, on Sat 20 Aug 2016 14:12:05 +0200, wrote:
I'd just like to check something: do we agree that libasound must be thread-safe by default (otherwise it breaks the application assumption that it's thread-safe)? If so, then there are thread-safety bugs:
Ok, now with the discussion on the portaudio list starting at
https://lists.columbia.edu/pipermail/portaudio/2016-August/000599.html
it seems the issue was in portaudio, which was hit by the locking behavior change.
Good to hear that it's been addressed in portaudio side.
But I still wonder in which code path the deadlock was triggered. Can anyone give the stack traces of deadlocked (multi-)threads?
Actually, it wasn't so much the locking itself, but thread cancellation during one call (snd_pcm_mmap_commit()) leaving the lock held and not released, which then balked when a cleanup call to snd_pcm_drop() attempted to aquire the lock. This occurred as a result of an 'Abort' action in Portaudio. It can be avoided by disabling cancelablity at all times except when waiting on poll(), though I have yet to be completely satisfied there are no snags in this approach, as cancelability is new to me!
OK, that relieves me. Let me know if you still find anything odd about the locking in alsa-lib, though.
thanks,
Takashi