From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Newsgroups: gmane.emacs.bugs Subject: bug#41242: Port feature/native-comp to Windows Date: Thu, 14 May 2020 15:40:28 -0300 Message-ID: References: <834ksi60zn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="114496"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 41242@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu May 14 20:41:18 2020 Return-path: Envelope-to: geb-bug-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 1jZInF-000TgV-Nv for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 20:41:17 +0200 Original-Received: from localhost ([::1]:47514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZInE-0001xD-OC for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 May 2020 14:41:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50342) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZIn0-0001um-9m for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 14:41:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:51499) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZImz-0005pc-NW for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 14:41:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jZImz-0006j5-Lj for bug-gnu-emacs@gnu.org; Thu, 14 May 2020 14:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Nicolas =?UTF-8?Q?B=C3=A9rtolo?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 May 2020 18:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41242 X-GNU-PR-Package: emacs Original-Received: via spool by 41242-submit@debbugs.gnu.org id=B41242.158948164825816 (code B ref 41242); Thu, 14 May 2020 18:41:01 +0000 Original-Received: (at 41242) by debbugs.gnu.org; 14 May 2020 18:40:48 +0000 Original-Received: from localhost ([127.0.0.1]:34812 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZIml-0006iK-VB for submit@debbugs.gnu.org; Thu, 14 May 2020 14:40:48 -0400 Original-Received: from mail-oi1-f180.google.com ([209.85.167.180]:45610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jZImk-0006i4-3r for 41242@debbugs.gnu.org; Thu, 14 May 2020 14:40:46 -0400 Original-Received: by mail-oi1-f180.google.com with SMTP id d191so5134871oib.12 for <41242@debbugs.gnu.org>; Thu, 14 May 2020 11:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=dvDujnA51aEB7OOzF5Y3r7RiVqgGoCT9TTKgecxOL5E=; b=mL7mUD8KQdwwOSzsJIqKotL+bXWn3Qg2pqAnbXtJA4PjbaVQrthyxZHK+TKX/9zJX9 CgqeoJ99okMSCDVipsrW3bCJxx1GxJB1CV4F3y91ALKAjzi+g4IRDeBtPlRdksYttFZZ uYHM9OY2cb7+eEr1W1XiJ1f12+0QCUXUQW4fddJdRVDm1zsKvrNkrmapMZ6VYjZ5pCUk FuRJ2qzfH741mjE6++mKrlYyqkTIlziD/Z/rIOTUYS+3FUAPrX0Y9QYZwO9wVI22yIO/ Ly4pkFAUwOHtsHIF0uirr5nL0srFfndxVIg/RBg6S9HQ0zbfogMugabRkVQlEkm/1Yul Zp4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=dvDujnA51aEB7OOzF5Y3r7RiVqgGoCT9TTKgecxOL5E=; b=KfCni1r+43RpMXyMI+QekUsKi9W2h6pHHVmHTYvh5LBT2s+D254BnpxSs+/MrHnGoV 5gNVmzBTRCCH3iq4N2h6KqsU5Xw4mbXl8IQ0duytYgsEIH13/qxvwtqyr58baWg//dUF xqwh3FzBx4G97ZKj9FGkC7GfjDLd4CeYco0vD5H3YW95YDw6eEvFHaDIoz1q3Jj0Bm27 qGNBTdxEbsiXIs+wODLsKIZVA1ahfZWte6XqmkwpWstojzLoZkcoWjgtXqcfu0Guk/lQ Hcb+ieRFZQwMvoEF6dPXDtOPdwvyHqVix6yrpj2pe79EXLNPQmMQv2tmt7b/7znaDduE CWjA== X-Gm-Message-State: AOAM5307h25BzxnmB8g+abrqaVy6VF23HiyWaGJklhT3EwVk4oE7BIMi Yy85Ggow9TaMmadjNPyzI6GX9uJI3YEwvNpTTeA= X-Google-Smtp-Source: ABdhPJz+MvCoRK1NP7PEm1JRAPJn8NHBSoN+O0nxB/s/BjXKbLzt7MR04m/6nehk9dzC6uGNP8C5LKQ0kXemfWL6efY= X-Received: by 2002:aca:e104:: with SMTP id y4mr2178551oig.120.1589481640270; Thu, 14 May 2020 11:40:40 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:180239 Archived-At: > Here we are really complexifying a problem that is not. IMO renaming > and having a list to do the clean-up are sufficient tools to solve it. You're right. I just think that renaming and a list do not guarantee that w= e always delete the files when we should. Consider this case: * Emacs1 and Emacs2 are two Emacs instances that load the same foo.eln file. * Emacs1 decides to recompile foo.el. To do that it renames foo.eln to foo.eln.old. It creates a new foo.eln and tries to delete foo.eln.old. It fails because Emacs2 has an open handle to it. * When Emacs2 closes it realizes that foo.eln has been renamed to foo.eln.o= ld and deletes it. That is the good case. If we are unlucky this is what may happen: * Emacs2 begins to close. It checks that foo.eln has not been renamed. Ther= efore it does not delete it. But it does not call FreeLibrary yet. * Emacs1 renames foo.eln to foo.eln.old. It tries to delete it but fails si= nce Emacs2 has an open handle. * Emacs2 finally calls FreeLibrary() and closes. In this case we are left over with a stale foo.eln.old. I don't think we ca= n have a race free algorithm. We could add a "GC" step to `load`, where it tries to find stale .eln.old files and removes them. Nicolas. El jue., 14 may. 2020 a las 15:13, Andrea Corallo () escribi= =C3=B3: > > Nicolas B=C3=A9rtolo writes: > > >> 1- eln files do not retain the orginal function bytecode. > > > > That should be easy to change. > > Sure but we don't want to do that because there's no reason to bloat the > eln. > > >> in any point of the code you can get the symbol-function of a defined > > function and leak it everywhere. > > > > This is why I said the GC should do it. It should be able to find all > > references. > > Yes but I can't *remove* objects that are referenced niether swap them. > See below. > > >> We can't technically "swap" functions definitions, the best we do is j= ust > >> redefine them that is set a certain symbol-function (what late load do= es). > > > > When the GC finds a Lisp_Object that points to a subr we want to unload= , > > it should replace it with one that points to its bytecode equivalent ve= rsion. > > No it cannot, if an object has been tested to say satisfy a predicate > you cannot change it for another one. It would break tons of code and > make the system totally un-debuggable. > > >> Even worst the function you want to remove could be active in the stac= k! > > > > You are right. I hadn't considered this. It can still be done, but woul= d need to > > wait until the function finishes. > > Yes, but when are all functions you want to get rid deactivated? > > Here we are really complexifying a problem that is not. IMO renaming > and having a list to do the clean-up are sufficient tools to solve it. > > -- > akrl@sdf.org