[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