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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
