[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#15602: bug#19235: make-fresh-user-module procedure leaks memory
From: |
Ludovic Courtès |
Subject: |
bug#15602: bug#19235: make-fresh-user-module procedure leaks memory |
Date: |
Fri, 24 Jun 2016 10:04:24 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Mark H Weaver <address@hidden> skribis:
> Andy Wingo <address@hidden> 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 ‘compile-file’ in a module excursion, and passing it a root
module that’s a copy of ‘the-root-module’, something 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’m not sure what you mean by “propagate permission”?
Ludo’.