[MUD-Dev] Introduction

Ling K.L.Lo-94 at student.lut.ac.uk
Wed May 14 08:19:15 CEST 1997


On Mon, 12 May 1997, Dan Root wrote:

> 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)

Forth...  I found Forth quite hard to get to grips with.  If I was at the
stage of choosing a language, I can imagine myself making up an object
orientated basic language.  Lists and stacks...

> 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).

One of my aims is to be able to run a separate process which can talk to
the server, run a scenario and then die in the corner.  How to do this,
I'm not quite sure, either via TCP, then another CPU can take the load, or
via shared memory, which looks sort of dodgy.

Then all sorts of extra things could be added.  Want support for a new mud
protocol to be added in?  Just add on another IO process.  Someone written
a CPU intensive AI for muds?  Add another IO process...  Naturally those
IO processes' codes can be combined whenever there's a full reboot.

> > 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. :)

Hmm...  Doesn't quite sound right, looks like lack of coding time.  Then
again....


  |    Ling				"Mental slavery,
_O_O_  Freshwater fish since 1976	 set my spirit free"





More information about the mud-dev-archive mailing list