[MUD-Dev] Re: Missing the point: OpenMUD, Gamora, Casbah, etc.

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Tue Oct 27 21:42:11 New Zealand Daylight Time 1998


[Bruce Mitchener, Jr.:]

 >The problem isn't execution time.  The problem is that 'y' will soon be very
 >large and handling out-of-memory situations is difficult.  Right now, if
 >Genesis runs out of memory, it shuts down.  This is obviously non-optimal.

 >Am I just missing something obvious?

Ah, OK. I had an option on the Amiga that was rather amusing. Since
everything was system wide, I just put up a requester asking the user
to free up some memory from something else. It wasn't *my* problem
that his computer ran out of memory! :-) I also had (and still have)
a limit of about 4K on strings. That would help in this example,
but not in others you mentioned.

I think the attitude I would take is that it is OK for the interpreter
to abort any particular piece of user-code if that code results in
something that overloads the server in some way. So, if there is a
tricky piece of scenario code that uses memory exponentially in regards
to the number of marbles someone is carrying, and an unlucky player
comes along and picks up the marble that exceeds the limits, then just
abort that 'pick up' command. Sure, you might leave the system state
in regards to that marble inconsistent, but then the user-programmer
that caused it should come and fix things. As long as the server
itself isn't troubled by these things. Not ideal, by any means!

If you are big fan of exception-oriented programming, then you can
claim that verbs that affect the system state should be prepared for
any system-generated exception at any point, and properly back things
out. Of course, you'd then never get anyone that wanted to program
on your system...

--
Don't design inefficiency in - it'll happen in the implementation. - me

Chris Gray     cg at ami-cg.GraySage.Edmonton.AB.CA




More information about the MUD-Dev mailing list