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 <ch...@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
