[vlc-devel] [PATCH 1/2] decoder: lock vout_thread_started when written

Thomas Guillem thomas at gllm.fr
Mon Jun 29 13:11:08 CEST 2020


Hello,

On Fri, Jun 26, 2020, at 16:14, Rémi Denis-Courmont wrote:
> Le perjantaina 26. kesäkuuta 2020, 14.26.01 EEST Thomas Guillem a écrit :
> > This variable is written from the ModuleThread or from the DecoderThread
> > when the module is unloaded. The lock need to be held when this variable is
> > written, since the DecoderThread read it with the lock held.
> 
> Well maybe, but the boolean presumably needs to be consistent with the 
> underlying state it describes, and that's not the case with the naive locking 
> below.
> 
> This looks like replacing a memory race with a functional race.

Indeed you are right.

If the vout is started from input_resource via input_resource_StartVout() then the input_resource should handle the vout start state internally. There should be only one (locked) function in input_resource that release the vout or keep it for later, and stop it if needed.

> 
> > ---
> >  src/input/decoder.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/src/input/decoder.c b/src/input/decoder.c
> > index 0c216bfca49..dd901f77b0c 100644
> > --- a/src/input/decoder.c
> > +++ b/src/input/decoder.c
> > @@ -479,7 +479,9 @@ static int ModuleThread_UpdateVideoFormat( decoder_t
> > *p_dec, vlc_video_context * res = input_resource_StartVout(
> > p_owner->p_resource, vctx, &cfg); if (res == 0)
> >      {
> > +        vlc_mutex_lock( &p_owner->lock );
> >          p_owner->vout_thread_started = true;
> > +        vlc_mutex_unlock( &p_owner->lock );
> >          decoder_Notify(p_owner, on_vout_started, p_vout, vout_order);
> >      }
> >      return res;
> 
> 
> -- 
> Rémi Denis-Courmont
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel


More information about the vlc-devel mailing list