[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