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

[Adam J. Thornton]

On Wed, Aug 05, 1998 at 09:43:48AM -1000, Nathan F Yospe wrote:
> 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?

Hmmmm.

Now that's an interesting question.

The initial answer is "because my world state lives in the database."

Which, as you point out, isn't an answer at all.

I suppose "Crash Protection" is one reason.  Namely, a room with no one in
it has no processes, so it occupies no memory, so any persistence is
implemented on the disk, currently in the form of PostgreSQL tables.  

So it's not exactly crash protection so much as it is that processes--and,
even more so, threads--are meant to be transient entities.  The only reason
I save the state of a room in memory is to limit the number of (very time
consuming) DB accesses.

Which does, I suppose, mean that you could read in a room state when the
first player enters, and write it out again when the last player leaves.
So all intermediate updates are, yes, merely for crash protection.  Depends
on how much time it takes to do it as to whether it's worth it.  I haven't
gotten far enough to tell what the optimal commit-room-state-to-DB
frequency is.

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

Makes sense,  I'm going to try to write as little wrapper code around the
base pthreads calls as possible.  Unless I really do use Java.

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

Hmmm.  I just don't see any clean way to do ropes.  I may at least
initially cheat and make ropes purely local phenomena, so you can (using
Inform-like syntax here) <<Attach Gondola Dock>> or <<Attach Horse Post>>
but not string a tripwire across the piazza.

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

I hear you there.

Adam
--
adam at princeton.edu 
"There's a border to somewhere waiting, and a tank full of time." - J. Steinman