[vlc-devel] Using logger during asynchronous close

[Alexandre Janniaux]

Hi,

On Wed, Mar 10, 2021 at 06:16:15PM +0200, Rémi Denis-Courmont wrote:
> 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.

It's more that it's not really using the logger infrastructure
to its potential with inheritency, so my question was trying
to consider other solutions, but yes.

But well, like you mentioned, the other variations are not
possible in the general case.

Mediacodec situation is hopefully the only one with a dedicated
thread/callbacks actually attached to the video context and not
the decoder_t object so hopefully it can just disappear in the
future.

Regards,
--
Alexandre Janniaux
Videolabs