GNU bug report logs - #19235
make-fresh-user-module procedure leaks memory

Previous Next

Package: guile;

Reported by: Chris Vine <chris <at> cvine.freeserve.co.uk>

Date: Sun, 30 Nov 2014 23:30:05 UTC

Severity: normal

Full log


Message #17 received at 19235 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Chris Vine <chris <at> cvine.freeserve.co.uk>
Cc: Mark H Weaver <mhw <at> netris.org>, ludo <at> gnu.org, 15602 <at> debbugs.gnu.org,
 19235 <at> debbugs.gnu.org
Subject: Re: bug#19235: make-fresh-user-module procedure leaks memory
Date: Wed, 22 Jun 2016 19:52:01 +0200
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?

Andy

On Fri 26 Dec 2014 19:26, Chris Vine <chris <at> cvine.freeserve.co.uk> writes:

> As far as I can tell the make-fresh-user-module procedure is not called
> by guile itself, and providing a global mutex for it with a binding
> enabling it to be called from scheme code seems to work fine.
>
> This also makes it straightforward to incorporate in a thread-safe
> way the code you suggested to free stale user modules.  However, as I
> mentioned, I am a bit reluctant to incorporate code which might break
> in the future.  Is there any possibility that a "delete-module!"
> procedure could be included within the public guile API for the next
> release of guile?  It seems like something that could be useful to
> anyone using non-default user modules in their code.
>
> Chris




This bug report was last modified 8 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.