[vlc-devel] [PATCH 2/7] video_output: read the vd inside the display_lock

Rémi Denis-Courmont remi at remlab.net
Wed Oct 9 18:15:06 CEST 2019


Le keskiviikkona 9. lokakuuta 2019, 18.50.23 EEST Steve Lhomme a écrit :
> On 2019-10-09 17:48, Thomas Guillem wrote:
> > On Wed, Oct 9, 2019, at 17:36, Steve Lhomme wrote:
> >> ---
> >> 
> >>   src/video_output/video_output.c | 3 +--
> >>   1 file changed, 1 insertion(+), 2 deletions(-)
> >> 
> >> diff --git a/src/video_output/video_output.c
> >> b/src/video_output/video_output.c
> >> index a5046913867..df27a402b8b 100644
> >> --- a/src/video_output/video_output.c
> >> +++ b/src/video_output/video_output.c
> >> @@ -1013,9 +1013,8 @@ static int
> >> ThreadDisplayRenderPicture(vout_thread_t *vout, bool is_forced)
> >> 
> >>       if (filtered->date != sys->displayed.current->date)
> >>       
> >>           msg_Warn(vout, "Unsupported timestamp modifications done by
> >> 
> >> chain_interactive");
> >> 
> >> -    vout_display_t *vd = sys->display;
> >> -
> >> 
> >>       vlc_mutex_lock(&sys->display_lock);
> >> 
> >> +    vout_display_t *vd = sys->display;
> > 
> > It is not needed since this variable is set before the thread is created.
> 
> At the very least it's easier to read than wonder why this right exactly
> before a lock. Why make things more complicated to read ?

On the complexity metric, it's exactly the same - not more or less 
complicated.

And it gives the wrong impression that the value needs the lock to be read. So 
it's really just worse. I agree with Thomas.

-- 
Реми Дёни-Курмон
http://www.remlab.net/





More information about the vlc-devel mailing list