bug#15602: bug#19235: make-fresh-user-module procedure leaks memory

[Mark H Weaver]

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.

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