On Wed, 21 Jan 1998, Angus Mezick wrote:
> 2) Shared objects - on a unix system is it allowed to replace a shared
> object without bringing down the mud if the functions in that object
> are not called while the copy is taking place. I am trying to think
> of a way to hot swap in changes to non core object file while the mud
> is running. (i.e. redit.c, spell_parser.c) a core file would be
> comm.c, interpreter.c, db.c(?).
No, shared objects are more than just raw code. For exaple, there is a
table with symbols the shared object requires: when the shared object
loads, that table has to be updated with the REAL locations of the
symbols. Just overwriting the .so can lead to different things depending
on what system you are on: if the file is mapped with MAP_DENY, I think,
you'll get a permission denied (it usually is done for binaries),
otherwise, your new copy will overwrite the mapped shared objects in the
running process' memory, with grave results.
If you remove the .so first, then everything will of course be all right:
the old file is still there, it just does not have a name. Of course, it's
the old code that's still mmaped.
So: you will have to unload the old file and map the new one. This is
near-impossible if you are not using dlopen: the linker uses some heavy
magic that is impossible to duplicate (at least as far as I know).
So (unless you are doing this already), you'll have to dlclose() the old
handle you get from dlopen, then dlopen again and dlsym all the symbols.
I have setup such a system, with maybe 50 commands and some functions
(e.g. nanny is in do/nanny.cc that gets compiled into do/o/nanny.so: the
old nanny *function* in the main program is now a nanny *variable*. The
nanny function is named "dyn_nanny" in the nanny.cc file and a init
function in that file will set the nanny global variable to dyn_nanny).
This works OK, and saves a lot of time when doing development on small
sections of code: I have the Makefile set up to send the MUD a certain
signal when the .sos are recompiled; the MUD then reloads all the .sos
whos timestamps have changed.
However, it's not too easy to set up (I have to move the code from the
main source to the do/ dir where the dynamically loaded objects are, set
up variables, change some prototypes etc.
And, it takes up a damn lot of memory when debugging , for same weird
reason. My gdb takes up 38 megabytes of memory when debugging the MUD,
which has a mere 12mb of memory (total not resident), a 8.4mb binary and
320k of those shared files - that just doesn't quite add up to 38
megabytes :()
=============================================================================
Erwin Andreasen Herlev, Denmark <erwin@pip.dknet.dk> UNIX System Programmer
<URL:http://www.abandoned.org/drylock/> <*> (not speaking for) DDE
=============================================================================
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST