[MUD-Dev] Dynamic Loading of Modules (was: Back on the list)

[J C Lawrence]

On Tue, 24 Feb 1998 00:12:50 PST8PDT 
Niklas Elmqvist<d97elm at dtek.chalmers.se> wrote:
> On Mon, 23 Feb 1998 coder at ibm.net wrote:
>> On 20/02/98 at 12:43 AM, Niklas Elmqvist <d97elm at dtek.chalmers.se>
>> said: 

> As I said earlier, I am aiming to decouple the actual core server
> from the world processing routines. Ideally, the main server would
> not even *know* it is running a MUD, it would be sort of a
> general-purpose core...

You have loosely described the general purpose network server espoused 
by such as the ColdX project.  Cold is currently being used to server
MUDs, web sites, as an SQL database frontend (for web) and otehr
purposes.

> ...and all the functionality such as DB
> management, socket I/O and AI would be implemented in free-standing
> modules separate from the main executable (at least, I envisioned
> this in the beginning). 

Which abstraction is deeper than Cold (or any other that I know of)
has attempted.

> I mentioned this to a RL friend of mine, and
> he pointed out that it all sounded very much like conventional OS
> architecture, especially like the module system of Linux kernels. 

I should point out that the original version of Shades was written to
run on a DEC PDP-11.  In truth Hazeii hacked RMS to be the MUD (mainly 
the command interpreter) so that effectively the OS _was_ the MUD.  

> In essence, what I discovered (to myself, that is, this is no doubt
> old news to some people) was that I could compile the core server
> with a base class with very little functionality, call it aClass,
> which called a factory function in a shared library, returning a
> pointer to an aClass object. Then, in the actual shared library
> (which is linked in with the main binary at run-time) I instead
> return an instance of a class called bClass, which inherits from
> aClass but which is totally unknown to the core server. Best of all,
> it works! That is, when I call the Execute() member function on the
> aClass handle in the core (which, unbeknowst to the core, points to
> a bClass object with redefined Execute() function), the correct
> Execute() function is called, that is bClass::Execute().

<bow> Cute.  Note that the vtable handling could easily get very
messy, especially if you abstract heavily, go for multiple
inheritance, or any of the nastier virtual structures. 

What platform/compiler BTW?

> Now, if aClass and bClass had been part of the same binary, I would
> not have been surprised. In fact, as you probably all know, this is
> called late binding in the O-O community and is an important feature
> of all serious O-O languages. However, what surprised and delighted
> me is that late binding *still* works even though the core and
> shared lib described above are separately compiled, and the bClass
> is totally unknown to the core! In my eyes, this is the ultimate
> test of late binding, and G++ pulled it off nicely! Incidentally, a
> friend (the one mentioned above) later reported that this is
> impossible in Windows-style DLLs.

Yup.  The features behind this working are that the name mangling and
vtable manipulations remained consistent.

> If you are wondering what the fuss is all about (or why this posting
> is getting so long), let me just say this: One application of this
> could be an Event class (in an event-driven system), whose base
> class is known to the core server (allowing for it to check the
> priority and expiration of the event, among other things), while the
> modules can inherit from the base class and redefine it to suit
> their particular needs. I also plan on using this technique for
> Handler objects which take care of things such as socket I/O,
> parsing, DB managment, etc, and the good thing about it is that I
> thus will be able to attach and detach the modules at run-time (to
> remedy a bug, for example). If the base classes are correctly
> implemented, the core will never even have to be recompiled and thus
> never rebooted (not accounting for fatal bugs, that is <g>)!

You're going to need a very clean connect/disconnect model (and likely
require single-threading unless you want to be excessively
entertained) to ensure that no code points are in or about to enter a
modeule which you wish to remove, or retain state data, or
back-references (such as instances) for the about-to-be-removed
module.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...