Re: dynamic reload of dynamic module not dynamic?

[Emanuel Berg]

Philipp Stephani wrote:

>>> 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?
>
> I don't think we have a single exhaustive location, but at
> the very least we'd need to invalidate all corresponding
> module functions before unloading a module, probably
> repointing them to some function that always signals an
> error. There is no mapping from module handles to
> corresponding module functions yet, but it shouldn't be
> terribly hard to add one (but I think first we should
> discuss whether the FR is important enough for that).
> Another category would be user pointers, since they are
> likely to point nowhere once a module gets unloaded.

I don't understand why anything has to be discontinued
necessarily, why can't it just be made available again and
what's new (or changed) is new? The way it already is
in Elisp?

That property with Emacs and Elisp is why we are all here
BTW :) If one had had to restart Emacs for every change no one
would ever get hooked and use Emacs for everything always.
Indeed it wouldn't be possible to do even ...

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