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