On Thu, 27 Apr 2017 10:45:55 +0200, Wischer, Timo (ADITG/SW1) wrote: > > Hi Takashi, > > All our test cases are working fine again with your commit [1]. > Thanks a lot. Thanks for checking. > I think all commits which introducing unlocked versions of the API functions can be reverted e.g [2]. > Or what do you think? Using the unlocked version is correct per se, so I don't think we need to remove it. thanks, Takashi > > [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
