Ok, I agree with your point. Without a severe retrofit (e.g. adding a bit to
the Lisp header on types that indicates whether it came from an external
module, and then before dereferencing anything with that bit set, checking
(somehow) for validity), unloading modules will be dangerous. (I wouldn't
call it scary or monstrous. ;))
For my particular situation, I can reinitialize the few global data
structures I've got in my module, without requiring an unload/load of the
module. I think that's what I'll do, since building a module that can be
used on a stock XEmacs outweighs the ease of use of the unload/reload cycle.
Patch withdrawn.
andrew
On 9/10/01 2:30 AM, Stephen J. Turnbull at turnbull(a)sk.tsukuba.ac.jp wrote:
>>>>> "Sean" == Sean MacLennan
<seanm(a)storm.ca> writes:
Hrvoje> Then why unload the module in the first place?
Sean> You need this whilst writing the modules.
Anyone who can handle writing a module can handle
make CFLAGS='-DDANGEROUS_SCARY_MONSTER'.
to make a module-testing platform. We're not talking about removing
the code.
Sean> I would not even care if there where *very* strict rules
Sean> about what you where allowed/not allowed to do with a
Sean> dynamic module if you wanted to unload it.
But there's nothing we can enforce. I'm not even sure that Andrew's
proposal for immediate reinitialization is good enough; in fact, I'm
pretty sure it isn't. If you change and recompile the module before
the unload, reload, reinitialize cycle, there's no reason to suppose
that the subrs and symbols would have the same addresses. That means
that any copies of those values taken before the reload would be
dangling references.
No, that is _not_ perverse or limited to module developers who can
handle it, either. Suppose the module comes in an RPM? In order to
detect that kind of change we'd have to use a unique-id setup like the
Linux kernel does with modversions.
So basically to be unloadable, the module would have to have no
Lisp-visible features. ;-)
-----------
Andrew Begel
Computer Science Division
UC Berkeley