[vlc-devel] Using logger during asynchronous close

Rémi Denis-Courmont remi at remlab.net
Wed Mar 10 16:16:15 UTC 2021


Le mercredi 10 mars 2021, 17:35:31 EET Thomas Guillem a écrit :
> 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).

A VLC object cannot be reference-counted. This is just moving the problem 
again.

As for using the LibVLC logger, that was always trivially possible. I reckon 
that's what Alexandre does not want to do.

-- 
Rémi Denis-Courmont




More information about the vlc-devel mailing list