* Samuel Thibault <samuel.thiba...@ens-lyon.org> [2016-08-20 14:12 +0200]:
> 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.
suppose that we should wait for a response of the maintainer
Takashi Sakamoto mentioned. If that dosn't come tto mind we either
have to disable pthread (we can't forsee what breaks then) or really
downgrade to 1.1.1.
Elimar
--
>what IMHO then?
IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
--posting from alex in debian-user--
signature.asc
Description: PGP signature
