> > 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. > > > Regards, > Daniel If not lazy as I said is bad design, not? Somebody designed pthread too. Frediano _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel