[MUD-Dev] Introduction

Dan Root dar at thekeep.org
Tue May 13 11:46:41 CEST 1997


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

> [Ling:]
> :What's a cycle?  When I mean disk based, I was thinking along the lines of
> :how present LPs work, load in object, hang around in memory until swapped
> :out due to lack of activity (including everyone leaving an area) or
> :destroyed.  Basically, I don't know of another method of doing it.  I
> :wanna keep the ability in LPs to play around objects whilst online and
> :crash the place. :)
> 
> I too would like to know what a 'cycle' is in this context.

The way the interpreter currently works is to keep a set of 'execution
contexts' (effectively threads, but handled by the interpreter, not
the OS), which it loops across running each context for n operations.
For lack of a better word I call it a 'cycle'. :)

Memory allocations for temporary things, including objects from the
database until I finish the cache, get carved out a region of memory
which is wiped clean at the end of a 'cycle', to prevent memory leaks
and the like (actually an mmap'd segment of /dev/zero which is just
remapped).

(And yes, I know that round robin is not optimally efficient.  But
it's both easy and fair, and prevents starvation, priority inversions,
and lots of other nasties one deals with in adaptive scheduling.)

[ description of standard caching algorithm snipped ]

> You can also chose between write-though and non-write-through, just
> like some CPUs let you (?). With a write-though cache, all changes are
> written to disk right away. With non-write-through, the changes are just
> made in the cache, and the cache entry must be written to disk before
> it can be purged and the space re-used. This purging can also be going
> on as a background activity. I use non-write-through, and don't have
> a background writer-to-disk.

I'd say this choice depends a lot on your design.  In my case, the API
for the cache is identical to the db.  The interpreter never really
talks to the db directly, but asks the cache, which may in turn call
the db itself to satisfy the request.  Given this, non-write-through
(write-back is the proper term I believe, but I'm not sure), makes a
lot of sense.   On the other hand, if you go directly to the db to get
things, then you definitely want write-through. :)


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



More information about the mud-dev-archive mailing list