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

Previous Next

Full log

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

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: Andy Wingo <wingo <at> pobox.com>, 15602 <at> debbugs.gnu.org,
 Chris Vine <chris <at> cvine.freeserve.co.uk>, 19235 <at> debbugs.gnu.org
Subject: Re: bug#19235: make-fresh-user-module procedure leaks memory
Date: Sat, 25 Jun 2016 20:50:56 -0400

ludo <at> gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw <at> netris.org> skribis:
>
>> 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’m not sure what you mean by “propagate permission”?

I mean: propagate permission to access the not-yet-committed module.
For example, suppose a program loads a module that runs the main event
loop as a top-level form in its body.  This module will never be
committed to the global module table, because it never finishes loading.
Now suppose that it spawns some new threads.  Those threads should have
access to the module.

Similarly, if a module uses 'par-for-each' to initialize some tables,
the spawned threads should have access to the module being loaded.

      Mark

Previous Next

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