[vlc-devel] Using logger during asynchronous close

[Steve Lhomme]

On 2021-03-10 17:24, Alexandre Janniaux wrote:
> 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.

In DXVA I execute code after the va object is dead. I'm just careful not 
to log anything during that time.