[vlc-devel] [PATCH] HLS: remove some useless mutex locks
funman at videolan.org
Wed Feb 8 19:42:23 CET 2012
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,
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
Spurious wakeups from the pthread_cond_timedwait() or
pthread_cond_wait() functions may occur. Since the
pthread_cond_timedwait() or pthread_cond_wait() does not imply
the value of this predicate, the predicate should be
re-evaluated upon such
More information about the vlc-devel