On 9/3/01 7:56 PM, Stephen J. Turnbull at turnbull(a)sk.tsukuba.ac.jp wrote: The issues I see with unloading a dynamic link module involve lisp symbols that point to entities in C that no longer exist (or rather are no longer guaranteed to exist in memory). Given that it's probably inefficient (and hard) to check every Lisp_Subr pointer for validity before invoking a C function, and that anyone can simply copy a lambda by value to another arbitrary lisp symbol, it's not feasible to identify and remove all lisp symbols that point to unloaded C objects. This is in the general case. However, let's propose new functionality for a more limited case. I have an external module that has a propensity for segfaulting every so often. My external module does not have any incestuous ties into XEmacs (though I have plenty of lisp objects that point to objects created by my external module). I would like to catch the segfaults that my external module generates, and unload and reload the module to reinitialize it. Then I throw an exception to Lisp which uses the notification to reinitialize all of my lisp functions/symbols that point into the external module. I wish I could just call an init() function in my external module to force it to reinitialize itself, but it's written in C++ and has lots of global constructors all over the place, which aren't easily accessed for reinitialization (if someone knows an easy way to do this, I'm all ears). So instead of a general unload-module function for XEmacs lisp, how about a reload-module function, which unloads and reloads the module in C code, and then runs the syms_of_*, vars_of_* and docs_of_* functions from the module to load Lisp symbols with new pointers into the external module? Andrew PS. For this general case of unload-module, I would actually create a new type of Lisp_Subr for external modules (or just add a bit to the normal Lisp_Subr struct), and if the bit is set, before invoking the C code or derefering a pointer into the external module, we check the page map to see if it's allocated to our heap; if not, we abort and throw an error to Lisp. ----------- Andrew Begel Computer Science Division UC Berkeley