[MUD-Dev] Introduction

[Dan Root]

cg at ami-cg.graysage.edmonton.ab.ca (Chris Gray) writes:

> :I'm still mixed on how this will work.  Part of me wants all programs
> :to be 'special' and live in their own little space.  Part of me wants
> :the model of attaching code to objects, and the rest of me wants
> :*everything* to be coded functions.  (For example, my description can
> :be a function that just returns a string, or actually does a bunch of
> :work and returns the string based on calculation and lookups).
> 
> So do both! Can you have conditional code at run time based on whether
> or not a property is present on an object? If so, just do something
> like (excuse the AmigaMUD syntax):
> 
>     action := object at descFunc;
>     if action ~= nil then
> 	description := call(action)(object);
>     else
> 	description := object at descString;
>     fi;
> 
> That way you can have special funcs when you need them, otherwise just
> have straight strings, which will take up less space.

Depending on my finalized language design, there may not be any
significant overhead to having a simple function which simply returns
a static string.  For example in a fictional forth-like manner I could
do something like:

: $Joe.desc "You see nothing special" ;

for a simple description or 

: $Joe.desc "You see a person.  He's wearing " $Joe.clothing strcat ;
: $Joe.clothing "a sweater" ;

In the case of most forth derivatives there's no overhead in the first
example as compared to storing just a string.  (actually, there's a
tiny amount, since you need an extra lookup to get from the function
to the string's address, but it's pretty negligible)

> :(FWIW, someone mentioned that process context switching was
> :expensive.  This is true, but your server is going to be switched out
> :anyways, as it's unlikely that nothing else is running on the machine
> :at all.)
> 
> Yes it is true. It will also make quite a lot of difference. It is an
> *added* overhead over other work the machine is doing.

To some degree.  On the other hand, it means that my interpreter only
needs to deal with one connection to the outside world (the single udp
socket to the network muxer) and that I can restart a new version of
the code without dropping all my player's connections.  In all the
various servers I've ever run (which admittedly lacks any of the LP
and Diku family) the server was far more bound by disk and network IO
than CPU.  (my design currently is setup such that the database can be
pulled out and put in a seperate process like the network muxer, thus
allowing the interpreter itself to never need to block).

It also means that my network code is a lot easier, since I never have
to worry about timing out a select() to allow the server to do it's
various other work.  The muxer just blocks until there's input for it
to process and the main interpreter can continue to work on whatever
tasks it needs to, checking every so often for new input from the
muxer.


> Also, all the commercial UNIXes I've worked with have SysV semaphores
> and shared-memory segments, so you can probably safely use those.

I though about this actually, but shared memory is evil.  Using udp
packets allows me to let the operating system buffer them on the
connection as packets of non-uniform size which I can pull off in
order as I need them.  I don't presume that I can do a better job than
my OS for this. :)

	-DaR
--
Dan Root - dar at thekeep.org