[vlc-devel] [PATCH] HLS: remove some useless mutex locks

[Rafaël Carré]

Le 2012-02-08 03:51, Frederic YHUEL a écrit :
> On Tue, Feb 7, 2012 at 7:27 PM, Rafaël Carré <funman at videolan.org> wrote:
>> Le 2012-02-07 11:48, Rémi Denis-Courmont a écrit :
>>> Le mardi 7 février 2012 18:33:50 Frederic YHUEL, vous avez écrit :
>>>> Out of the blue?
>>>
>>> The critical section does nothing other than signal the condition.
>>>
>>>> Do you mean that we should maintain the state (ALIVE | WAITING |
>>>> TERMINATED ) of the downloading thread in a shared variable, and that
>>>> we should call vlc_cond_signal() only after having checked the state?
>>>
>>> I am referring to the model behind POSIX condition variables, which is the one
>>> that VLC condition variables follow.
>>
>> Check the manpage of pthread_cond_wait it has some explanation.
>>
> 
> Thanks Rémi and Rafaël. I guess that since a condition wait is a
> cancellation point, we just have to send a cancellation request,
> rigtht?

I don't know what you're trying to do.

If you cancel the thread make sure all its resources are released.

> 
> For the second chunk of code, in hls_Read, I guess that the mutex
> should be acquired sooner, before p_sys->playback.segment is
> incremented, right?

As soon as the condition (predicate in the manpage) that you're
signalling is accessed.

Check modules/xdg/inhibit.c , the condition is p_sys->suspend and the
module takes care of spurious wake ups in pthread_cond_wait with a
while() loop.


 Spurious  wakeups  from   the   pthread_cond_timedwait()   or
       pthread_cond_wait()    functions    may    occur.   Since   the
 return   from
       pthread_cond_timedwait() or pthread_cond_wait() does not imply
anything  about
       the  value  of  this  predicate, the predicate should be
re-evaluated upon such
       return.