Jaroslav Kysela, on Wed 17 Aug 2016 19:46:42 +0200, wrote: > Dne 16.8.2016 v 23:03 Samuel Thibault napsal(a): > > - snd_pcm_new seems to initialize pcm->thread_safe to 0 by default, this > > does not seem safe. The attached patch initializes it to 1, which > > fixes the bug in our tests. > > > > - snd_pcm_hw_open_fd forces it to 1, thus ignoring what snd_pcm_new set. > > The thread_safe has this meaning: > > 0 - the pcm plugin is not thread safe > 1 - the pcm plugin is thread safe (actually only the hw plugin) > -1 - disable thread safety So now with rethinking all of this, I'm starting to understand: from reading the variable name, I would have thought "thread_safe=1" means "I want thread safety thanks to a mutex", while apparently it means "the plugin is already thread-safe, there is no need for a mutex"... Really, all of this should be documented clearly along the source code, otherwise people will get it wrong. 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: the mentioned Debian report is far from alone, the upgrade to the newer libasound has severely broken quite a few applications, I'm at the point of advising the Debian maintainer to just revert to the previous version for Stretch, otherwize we'll be shipping just very-buggy software. Samuel _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
