[MUD-Dev] Re: Socket-Script: Socket-capabable script language and matching library

[Nathan F Yospe]

On Wed, 5 Aug 1998, Adam J. Thornton wrote:

<snip stuff others answered better than I could>

:I'm not actually too worried about the N-processes-for-N-players problem,
:mainly because empty rooms are kind of boring, and I suspect that players
:will quickly congregate in rooms with other players.  If I have per-room
:scoping then I have a reasonably natural solution to the data
:representation problem by making each room a process and making its object
:data available to all threads (player objects) running in it.  Object data
:is ultimately represented in the database backend, but for each process it
:is locally represented in in-memory data structures, which, as they change,
:get written to a low-priority database queue thread, which runs when the
:cycles are free or gets flushed on some schedule (e.g. every thirty seconds
:if it hasn't had a chance to run yet).

Interesting... I've got a lot of "runtime state" data that never gets
written to disk. My disk/memory storage is designed to be completely
transparent, so anything that is on disk could reside in memory... but
the thing that sort of occurs to me here is... is this just for crash
protection? Or is there some basic reason to duplicate information?

I use to-disk conversion for reused (derived from and duplicated)
objects, and for anything that will be distributed across servers (I'm
still working on this. The design is progressing well in the scraps of
time I can recover on weekends. I'll be starting coding again, after a
long, long hiatus, in a few weeks. Scheduled 15 hours a week for this.)
I also do to-disk conversion... and memory deallocation... for anything
in a projection zone - one where the current thread has gone inactive,
and the geographical region has been slated for long term updates. The
to-disk occurs immediately on projection stage one. Memory deallocation
occurs quite a bit later, at projection stage two, after a few hours of
inactivity.

:One thing I haven't worked out yet in my model is just what to lock when
:players move globally visible objects.  I could lock everything in the
:room--that is, put a mutex around the room data for as long as it took to
:copy the transaction to the DB queue thread--but that locks a lot of stuff
:that doesn't need to be locked.  If I'm willing to do the computation, I
:can lock the object tree with the manipulated object's parent at its head
:(that is, if an orange is in the cupboard, lock the cupboard and everything
:in it...but if an orange is in a shoebox in a cupboard, do I lock the
:cupboard or the shoebox?), or I can cheat a little and lock the region of
:space that contains the object in question (each room has a Cartesian grid
:underlying it--if the orange in the shoebox in the cupboard is at (5,5),

As I use a rather distinctly different model (everything is a container,
and threads occur at the lowest "occupied" container and up, with main 
locks projecting upward to the maximum "event space" of an event... I use
process locks instead of mutexes... my own thread model, based on pthreads.
In short, I reduce everything to single threaded for regions of possible
conflict using a you-enter-first bailout, then reengaging lower levels. I
have recently been looking at a way to allow lower level threads along all
but affected branches of the process tree to continue. Again... I really
have been meaning to post a bunch of design documentation for this, but I
have had time pinching like you wouldn't believe. Combination of work, my
practice schedule (race on Saturday, we've stepped up practice), GF, etc.
And the design docs need some rework before I post them. I'm not planning
to post the algorithms for some of it... I spent tens of hours working the
math for those, and plan to keep them.

:lock all objects which are at (5,5)).  This works up until I want objects
:that occupy multiple spaces; for instance, ropes.  However, ropes are such
:hideously intractable objects (rec.arts.int-fiction yells about this at
:least once a month) that I'm tempted to go with a purely localized object
:model and do spatial locking, at least for now.

Ropes. Ah. They, and their kin, trouble me too... they're always locking
in the event tree several layers up from the current containter. Well, in
the end, I decided ropes were like radiation. They pass messages back,
and if there are time delays and hicoughs occasionally... so be it. The
rope's a little stretchy. Seems to keep the threads running smoother.

I've got to write the client, so I can actually *see* the world-state,
instead of printing out numerical models.
--

Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Student, University of Hawaii at Manoa, Physics Dept.
yospe#hawaii.edu nyospe#premier.mhpcc.af.mil http://www2.hawaii.edu/~yospe/