[vlc-devel] [PATCH] Deprecate vlc_clone_detach()
    Rémi Denis-Courmont 
    remi at remlab.net
       
    Sun Sep  6 18:49:51 CEST 2020
    
    
  
Le sunnuntaina 6. syyskuuta 2020, 19.17.45 EEST Romain Vimont a écrit :
> On Sun, Sep 06, 2020 at 04:31:07PM +0300, Rémi Denis-Courmont wrote:
> > Le sunnuntaina 6. syyskuuta 2020, 16.15.05 EEST Romain Vimont a écrit :
> > > Hi,
> > > 
> > > On Sun, Sep 06, 2020 at 03:32:27PM +0300, Rémi Denis-Courmont wrote:
> > > > The documention outright lies about LibVLC waiting to make this
> > > > functon
> > > > safe. There are no ways to use this function safely other than linking
> > > > LibVLC statically into the application, which is not *generally*
> > > > practical.
> > > 
> > > I have mixed feelings about this.
> > > 
> > > I'm wondering if it would not just be better to just document that
> > > unloading the libvlc library is undefined behavior.
> > 
> > We used to support this until Filip broke it.
> 
> If we consider that it is not safe to unload a library (e.g. loaded by
> VLC, hence module_unneed() not calling dlclose()), then nothing is
> broken.
There never was such an option.
LibVLC runs on run-times that do unload (e.g. MSVCRT, glibc), and run-times 
that don't (e.g. musl). It runs in frameworks that do close LibVLC and 
frameworks that don't.
You can't just arbitrarily remove a combination, especially not the "clean" 
one.
And there's really no justifications. A detached thread saves nothing. 
Literally all you need to keep around until join is a flag/semaphore and a 
result pointer. Everything can be destroyed when the thread exits even if it 
is not detached, including all kernel resources.
-- 
レミ・デニ-クールモン
http://www.remlab.net/
    
    
More information about the vlc-devel
mailing list