[vlc-devel] [vlc-commits] auhal: implement drain

David Fuhrmann david.fuhrmann at gmail.com
Tue Mar 26 19:06:12 CET 2013


Am 24.03.2013 um 22:04 schrieb Rémi Denis-Courmont <remi at remlab.net>:

> Le dimanche 24 mars 2013 23:00:14, David Fuhrmann a écrit :
>> Am 24.03.2013 um 21:56 schrieb "Rémi Denis-Courmont" <remi at remlab.net>:
>>> Le dimanche 24 mars 2013 22:49:46, David Fuhrmann a écrit :
>>>> @@ -1287,6 +1299,10 @@ static OSStatus RenderCallbackAnalog(vlc_object_t
>>>> *p_obj, VLC_UNUSED(inNumberFrames);
>>>> 
>>>>    }
>>>> 
>>>> +    vlc_mutex_lock(&p_sys->lock);
>>>> +    vlc_cond_signal(&p_sys->cond);
>>>> +    vlc_mutex_unlock(&p_sys->lock);
>>> 
>>> Please tell me, where the hell did you copy this (wrong) code from? Why
>>> does everybody developer make the same mistake in turn, inspite of the
>>> documentation and so many negative review comments??
>> 
>> I saw this in at least 2 or 3 audio output plugins.
> 
> KAI is the only other audio output plugin calling vlc_cond_signal(), and does 
> so correctly and quite differently. Well, WaveOut uses vlc_cond_broadcast() but 
> also correctly and not like this patch.

Hi Remi,

If I parsed the relevant parts of your emails in the right way, I assume that you want to complain that I did not extended the scope of the mutex lock to the manipulation of the buffer.

Please note that I already thought in doing so, before committing.
But the CircularBuffer already has some thread safety mechanisms using atomic operations. For this scenario I assumed that these will suffice for proper thread synchronization.

Please take a closer look of the implementation of the circular buffer, and give some concrete remarks why you believe that current mechanisms are not sufficient.
I am always happy when I learn something due to remarks from you (or from others).

With best regards,
David




More information about the vlc-devel mailing list