From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.help Subject: Re: dynamic reload of dynamic module not dynamic? Date: Tue, 19 Apr 2022 07:13:52 +0200 Message-ID: References: <87o810mic0.fsf@zoho.eu> <22BE2D29-B50B-4164-B0AC-4BDFA62A20EC@gmail.com> <87lew3lb94.fsf@zoho.eu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GjYKNQCvYG8sjwZd" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11218"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 19 07:15:15 2022 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nggCp-0002iK-7m for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 19 Apr 2022 07:15:15 +0200 Original-Received: from localhost ([::1]:49104 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nggCm-0000rN-W8 for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 19 Apr 2022 01:15:13 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nggBa-0000rE-Ha for help-gnu-emacs@gnu.org; Tue, 19 Apr 2022 01:14:00 -0400 Original-Received: from mail.tuxteam.de ([5.199.139.25]:44406) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nggBY-00079O-8S for help-gnu-emacs@gnu.org; Tue, 19 Apr 2022 01:13:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tuxteam.de; s=mail; h=From:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:To:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bSyf+DCrO5m4wdLY1oPNXB2wFX/EK4eKvk/lNXRX/Ik=; b=P5Qlg5P66pwMkBKVpfLAgT9u2/ mQUvs94EupIENuX9Z+32gc69XdCqn7u8mr8Tvo4en5mxbMgR5wQoC8nqfSLTG+t/skWIgocIEqP1K pMIfzD3kgNJlYsaLvuBl9KIkyegzTZx9y4I2U9j624/KyYIKKsKtLGvaDlU/aBkCD98BWeJi+3fym p6gHKrr1/PL3xdweakNGwnvt5d4sJQmENRS32ChZCUCKZj9b2vq4uobaatluZ31X3GsISQoa9eUS2 Jw7gjxsRjnBKrXNy8RP6lp+OXE8gYywNwMghDpmnBVdY4u4+yVho3qcr4CqWY5MdyJPur9QGqtQ/U 0JrRTC7w==; Original-Received: from tomas by mail.tuxteam.de with local (Exim 4.94.2) (envelope-from ) id 1nggBU-0006LK-7J for help-gnu-emacs@gnu.org; Tue, 19 Apr 2022 07:13:52 +0200 Content-Disposition: inline In-Reply-To: <87lew3lb94.fsf@zoho.eu> Received-SPF: pass client-ip=5.199.139.25; envelope-from=tomas@tuxteam.de; helo=mail.tuxteam.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:136953 Archived-At: --GjYKNQCvYG8sjwZd Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 17, 2022 at 10:12:55PM +0200, Emanuel Berg via Users list for t= he GNU Emacs text editor wrote: > Philipp Stephani wrote: >=20 > >> 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. >=20 > 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 =66rom 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#16= 44 --=20 t >=20 > --=20 > underground experts united > https://dataswamp.org/~incal >=20 >=20 --GjYKNQCvYG8sjwZd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCYl5FCQAKCRAFyCz1etHa RmCvAJ9//OnKaaDB/2dx55B1T33biKt/HQCeNbXAziSq+NtljkHwlkK0i1Ql5dk= =9drA -----END PGP SIGNATURE----- --GjYKNQCvYG8sjwZd--