From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#19235: make-fresh-user-module procedure leaks memory Date: Thu, 23 Jun 2016 10:17:48 -0400 Message-ID: <878txwrnub.fsf@netris.org> References: <20141130232834.32cbf5b2@bother.homenet> <87iohn51dc.fsf@yeeloong.lan> <20141207141903.1347c764@bother.homenet> <20141226182608.24c7dabf@bother.homenet> <87por9ru0u.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1466691612 31154 80.91.229.3 (23 Jun 2016 14:20:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Jun 2016 14:20:12 +0000 (UTC) Cc: 15602@debbugs.gnu.org, ludo@gnu.org, Chris Vine , 19235@debbugs.gnu.org To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Thu Jun 23 16:20:01 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 1bG5U8-0003Sz-87 for guile-bugs@m.gmane.org; Thu, 23 Jun 2016 16:20:00 +0200 Original-Received: from localhost ([::1]:36938 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG5U7-0000ZL-Bc for guile-bugs@m.gmane.org; Thu, 23 Jun 2016 10:19:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55549) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG5TI-00005E-6U for bug-guile@gnu.org; Thu, 23 Jun 2016 10:19:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bG5TC-0005IG-Nt for bug-guile@gnu.org; Thu, 23 Jun 2016 10:19:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40426) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bG5TC-0005IB-Kx for bug-guile@gnu.org; Thu, 23 Jun 2016 10:19:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bG5TC-00038D-JS for bug-guile@gnu.org; Thu, 23 Jun 2016 10:19:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Thu, 23 Jun 2016 14:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19235 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 19235-submit@debbugs.gnu.org id=B19235.146669148911964 (code B ref 19235); Thu, 23 Jun 2016 14:19:02 +0000 Original-Received: (at 19235) by debbugs.gnu.org; 23 Jun 2016 14:18:09 +0000 Original-Received: from localhost ([127.0.0.1]:52761 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bG5SK-00036p-Qs for submit@debbugs.gnu.org; Thu, 23 Jun 2016 10:18:09 -0400 Original-Received: from world.peace.net ([50.252.239.5]:32984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bG5SJ-000363-0T; Thu, 23 Jun 2016 10:18:07 -0400 Original-Received: from c-73-253-48-168.hsd1.ma.comcast.net ([73.253.48.168] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1bG5SC-0007iY-6c; Thu, 23 Jun 2016 10:18:00 -0400 In-Reply-To: <87por9ru0u.fsf@pobox.com> (Andy Wingo's message of "Wed, 22 Jun 2016 19:52:01 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.95 (gnu/linux) 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:8162 Archived-At: 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. 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. 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. Thoughts? Mark