Mark H Weaver <m...@netris.org> skribis: > Andy Wingo <wi...@pobox.com> 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’.