Hi Takashi, All our test cases are working fine again with your commit [1]. Thanks a lot. I think all commits which introducing unlocked versions of the API functions can be reverted e.g [2]. Or what do you think? [1] http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=1cb217ead9aff029f194208bf484be1ba956b194 [2] http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=24e63b75275e9c923c336b8dba3919b980e8f234 Best regards Timo Wischer Software Group I (ADITG/SW1) Tel. +49 5121 49 6938 -----Original Message----- From: Takashi Iwai [mailto:tiwai@xxxxxxx] Sent: Freitag, 21. April 2017 20:44 To: Wischer, Timo (ADITG/SW1) Cc: alsa-devel@xxxxxxxxxxxxxxxx Subject: Re: FW: Further goals of thread-safe PCM API On Thu, 20 Apr 2017 17:42:06 +0200, Takashi Iwai wrote: > > On Thu, 20 Apr 2017 16:01:47 +0200, > Wischer, Timo (ADITG/SW1) wrote: > > > > Hi everyone, > > > > I am wondering about the implementation of the new thread-safety feature [1]. > > There are so many issues with deadlocks (e.g. [3]) which were already solved but also which are not yet solved. > > > > Why do you not using a recursive mutex to avoid most of this deadlocks? > > Using PTHREAD_MUTEX_RECURSIVE as the pthread attribute [2]. > > It sounds like a good idea. > Although the plugin should be written not to cause deadlock, it's > better to avoid such a pain by allowing the recursive lock. > > Care to test and submit the proper patch? Never mind, I committed a quick fix to git repo now. Thanks for the suggestion! Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
