all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Emanuel Berg via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: dynamic reload of dynamic module not dynamic?
Date: Tue, 19 Apr 2022 16:01:55 +0200	[thread overview]
Message-ID: <87a6chuq7g.fsf@zoho.eu> (raw)
In-Reply-To: CAArVCkTF=F+CyNb4UM8VOkqnarbVR9rQhVap8J9v6-zo14nG4A@mail.gmail.com

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




  reply	other threads:[~2022-04-19 14:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-17  4:42 dynamic reload of dynamic module not dynamic? Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-17 18:31 ` Eduardo Ochs
2022-04-17 20:18   ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-17 18:44 ` Philipp Stephani
2022-04-17 20:12   ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-19  5:13     ` tomas
2022-04-19 11:08       ` Emanuel Berg via Users list for the GNU Emacs text editor
2022-04-20 17:06         ` Eli Zaretskii
2022-04-19 12:46     ` Philipp Stephani
2022-04-19 14:01       ` Emanuel Berg via Users list for the GNU Emacs text editor [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-07-04  7:00 Psionic K

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a6chuq7g.fsf@zoho.eu \
    --to=help-gnu-emacs@gnu.org \
    --cc=moasenwood@zoho.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.