From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#15602: bug#19235: make-fresh-user-module procedure leaks memory Date: Fri, 24 Jun 2016 10:04:24 +0200 Message-ID: <8760szau7r.fsf@gnu.org> References: <20141130232834.32cbf5b2@bother.homenet> <87iohn51dc.fsf@yeeloong.lan> <20141207141903.1347c764@bother.homenet> <20141226182608.24c7dabf@bother.homenet> <87por9ru0u.fsf@pobox.com> <878txwrnub.fsf@netris.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466755525 18183 80.91.229.3 (24 Jun 2016 08:05:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2016 08:05:25 +0000 (UTC) Cc: 15602@debbugs.gnu.org, Chris Vine , 19235@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Jun 24 10:05:14 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bGM6z-000880-RW for guile-bugs@m.gmane.org; Fri, 24 Jun 2016 10:05:13 +0200 Original-Received: from localhost ([::1]:41744 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGM6y-0005Tk-QN for guile-bugs@m.gmane.org; Fri, 24 Jun 2016 04:05:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGM6p-0005SA-KJ for bug-guile@gnu.org; Fri, 24 Jun 2016 04:05:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGM6o-0006vu-GH for bug-guile@gnu.org; Fri, 24 Jun 2016 04:05:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40982) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGM6o-0006vq-C9 for bug-guile@gnu.org; Fri, 24 Jun 2016 04:05:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bGM6o-0001Hr-6W for bug-guile@gnu.org; Fri, 24 Jun 2016 04:05:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 24 Jun 2016 08:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15602 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 15602-submit@debbugs.gnu.org id=B15602.14667554794885 (code B ref 15602); Fri, 24 Jun 2016 08:05:02 +0000 Original-Received: (at 15602) by debbugs.gnu.org; 24 Jun 2016 08:04:39 +0000 Original-Received: from localhost ([127.0.0.1]:53316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGM6Q-0001Gj-OR for submit@debbugs.gnu.org; Fri, 24 Jun 2016 04:04:38 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38742) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGM6P-0001GW-7z for 15602@debbugs.gnu.org; Fri, 24 Jun 2016 04:04:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGM6H-0006oT-4b for 15602@debbugs.gnu.org; Fri, 24 Jun 2016 04:04:32 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGM6H-0006oP-0x; Fri, 24 Jun 2016 04:04:29 -0400 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:47396 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bGM6F-0003tR-VS; Fri, 24 Jun 2016 04:04:28 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 7 Messidor an 224 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <878txwrnub.fsf@netris.org> (Mark H. Weaver's message of "Thu, 23 Jun 2016 10:17:48 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8205 Archived-At: Mark H Weaver skribis: > Andy Wingo writes: > >> In many ways I think Ludovic was right in #15602 -- we should allow >> excursions to isolate changes to the module tree. Sometimes you want an >> excursion to never add a module to the tree. Sometimes you do, but >> maybe all in one go and with a mutex, to avoid races -- like, you could >> load a file or evaluate some code in a private fork of the module tree, >> but then commit it to the main tree afterwards. Is that a sensible >> thing? > > Yes, I agree. In fact, I'd been thinking of something along those lines > to enable thread-safe module loading. More specifically, I was thinking > that there should be a fluid variable that contains some additional > modules that are not yet committed to the global module tree. > > Briefly, when a module is auto-loaded by a thread, the new module would > initially be visible only to that thread, and also to any threads > spawned by that thread during the auto-load. Any attempts to access the > module from other threads would block until the module is either fully > loaded. That sounds like a nice idea. In the current state of things, perhaps this behavior could be emulated by running =E2=80=98compile-file=E2=80=99 in a module excursion, and passin= g it a root module that=E2=80=99s a copy of =E2=80=98the-root-module=E2=80=99, somethin= g like that (though that would probably perform badly.) > One potential issue that has been troubling me is that in Guile's model, > there's no guarantee that a module will _ever_ finish loading. I think the fact that we evaluate all the top-level forms is problematic. The R6RS phases were a great idea. :-) > The main program itself could simply run from the auto-load. That's > why I think it's important to propagate permission to threads created > during the auto-load, but maybe there will still be problems. I=E2=80=99m not sure what you mean by =E2=80=9Cpropagate permission=E2=80= =9D? Ludo=E2=80=99.