[vlc-devel] Using logger during asynchronous close

Thomas Guillem thomas at gllm.fr
Wed Mar 10 15:35:31 UTC 2021



On Wed, Mar 10, 2021, at 16:30, Alexandre Janniaux wrote:
> Hi,
> 
> On Wed, Mar 10, 2021 at 04:32:36PM +0200, Rémi Denis-Courmont wrote:
> > Le lundi 8 mars 2021, 19:23:11 EET Alexandre Janniaux a écrit :
> > > > Either you fix the design not to perform in(s)ane things, or you devise a
> > > > weak reference mechanism. The later means that log messages will sometime
> > > > get lost, which is far from good.
> > >
> > > Just so this is clear, what is the «insane/inane» thing?
> >
> > Expecting the decoder object and/or its logger to outlive the life cycle
> > defined by owner of decoder.
> >
> > > However asynchronously closing the resources
> > > allocated from the decoder should/has become quite common in the code base,
> >
> > No? There are two types of resources that the decoder can create and might
> > outlive it: decoded data (audio blocks, pictures and SPUs), and ES formats.
> > They are all buffers and/or data. They are not processing elements. They don't
> > need a log attached to them.
> 
> Video context can also outlive the decoder_t.

We know that video context can't outlive libvlc, thus the logger, since vout, players are destroyed before the logger. Maybe we can attach a logger to the video context? (or maybe make it a vlc_object_t).

> 
> > And in any case, what's not possible is not possible.
> 
> Fair enough, maybe the mediacodec OutThread code should
> just not log into the decoder_t object at first. I'll
> see what I can do that makes sense there.
> 
> Thanks,
> --
> Alexandre Janniaux
> Videolabs
> _______________________________________________
> 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