[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