[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