Re: [PATCH spice-gtk] Add call of gst_deinit at program exit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Oct 19, 2017 at 08:53:08AM -0400, Frediano Ziglio wrote:
> > 
> > On Thu, Oct 19, 2017 at 08:03:00AM -0400, Frediano Ziglio wrote:
> > > > 
> > > > 
> > > > In fact non-trivial shared libraries should generally never be unloaded,
> > > > even
> > > > if they were originally dlopend.  If the library has used a pthread local
> > > > with
> > > > a destructor function, then unloading the library will remove the code
> > > > that
> > > > contains the impl of the destructor. When the thread later exits and its
> > > > thread
> > > > locals are cleaned up, the application will crash & burn.
> > > > 
> > > > Many libraries, including libvirt, will link with '-z nodelete' to
> > > > prevent
> > > > unloading of the library even if dlclose() is called, to avoid these kind
> > > > of crashes.
> > > > 
> > > > IOW getting perfect "cleanup" is just a fools errand and will likely
> > > > create
> > > > obscure problems down the road that are worse than the problems the
> > > > cleanup
> > > > is trying to solve. Just accept normal process resource cleanup when the
> > > > application exits.
> > > 
> > > This is a point for Windows... they manage to have unloading working.
> > > Also you can unload Linux kernel modules.
> > > I honestly find these reasoning a lazy excuse to bad programming and
> > > design.
> > 
> > Calling it laziness is completely missing the point. There is *nothing*
> > in the pthreads API that lets you avoid the problem with thread local
> > destructors described above, no matter how much we want to fix it. The
> > only "solution" is to not use pthread locals at all, which is not practical.
> > 
> 
> If not lazy as I said is bad design, not? Somebody designed pthread too.

POSIX designed pthreads, but dlopen comes from Solaris, only after that
adopted as part of POSIX. The situation is just a result of the way the
standard has organically grown over time, not been designed top down to
deal with all possible interactions

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]