Re: dynamic reload of dynamic module not dynamic?

[<tomas@tuxteam.de>]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Sun, Apr 17, 2022 at 10:12:55PM +0200, Emanuel Berg via Users list for the GNU Emacs text editor wrote:
> Philipp Stephani wrote:
> 
> >> It seems recompiling the C for an Emacs dynamic module and
> >> then loading the new SO file from the same Emacs instance
> >> that loaded the old doesn't get you the new stuff?
> >
> > Yeah, we never call dlclose on the returned shared object
> > handle, so reloading a module will only increment the
> > handle's reference count. It might make sense to support
> > reloading in some way (by having unload-feature eventually
> > call dlclose), but it's not trivial: we need to be careful
> > to invalidate all references to affected module functions
> > before calling dlclose.
> 
> Okay, where are they stored then so one can apply invalidate
> to all members and then call dlclose and `load' again?

This is not completely trivial. Parts of the application may
have become dependent on the loaded library. That's why dlclose()
is described as "advisory" [1]. It may do, but then, it might
not.

Just imagine your application storing a pointer to some function
in that DL. You remove it, the address space becomes free and
is replaced by something totally different. The above code calls
into this pointer and... kaboom. You literally pulled the rug
from under your poor application :-)

Now you would say you wouldn't ever hoard pointers to random
library functions, but that's exactly what the dynamic loader
is doing for you.

Not saying it's impossible, but that it's trickier than it seems.
Most of the time you'll have to live with several incarnations
of "some functions" because your "old function" refuses to die.
Most applications choose to restart.

Just search for "dlclose problem" in the GNU libc mailing list
to see what I mean. Here's [2] one.

Cheers

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/dlclose.html
[2] https://sourceware.org/pipermail/libc-help/2010-November/thread.html#1644

-- 
t


> 
> -- 
> underground experts united
> https://dataswamp.org/~incal
> 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]