[DGD]statedumping

[Kris Van Hees]

On Wed, May 10, 2000 at 11:23:51PM +0200, E. Harte wrote:
> On Wed, 10 May 2000, Kris Van Hees wrote:
> > Last I checked, it called fatal() which effectively terminates the driver
> > process.
> 
> In human-speak: "It crashes and core-dumps" (if you allow it and have
> enough diskspace for one). :-)

Well, it's an abort().  I definitely differentiate between a real crash and an
intentional abort().  Still, perhaps an exit() would have been more graceful.
Dworkin... Any special reason why fatal() is doing an abort() instead?

> [...]
> > I'd say that the vast majority of the available mudlibs have enormous object
> > leaks in them.
> 
> Could you point out any?  I'd say that DGD makes it very easy for a
> developer to track objects and make sure the basis is airtight when it
> comes to leaking objects.  The most likely place to find any such leaks is
> in places where creators/wizards add to the game, not in the mudlib.
> 
> > It is one of the stronger reasons why I am an advocate for
> > actually doing development on a test version of the actual mud, and to not
> > move code to the production version until after an proper testing has taken
> > place.
> 
> I don't see why.  In a decent mudlib you'd have limitations in place that
> avoid an object going berzerk and creating clones or adding call_outs
> until the mud crashes.

With my statement I mean that many existing mudlibs do not have sufficient
code in place to prevent a creator from writing objects that might lay in
object space forever.  It's simply one of the risks involved with allowing
people to add code to your system (and obviously an acceptable risk for muds,
since it is the core of the way LPmuds work).  You can use quotas etc to
limit it to a certain extend, but in the same way that disk quotas tend to
not solve that much (alot of people simply using up their entire quota in
the end), it's not usually a sufficient safeguard.

And it does not solve the problem that your either have to make the system
unrealistic (objects dropped in rooms get cleaned up regularly), complex
(objects dropped in rooms get destructed but knowledge about them is retained
so they can be recreated when someone wanders into the room), or live with
the risk.  (Incidentally, on another CS issue, Russ Cox (Bell Labs) pointed
out in a newsgroup posting that once you have users, you open yourself up to
denial of service attacks/accidents unless you make your system so restricted
that it is barely usable).

My believe that a separate development copy is a good idea is mostly based on
the fact that any piece of code can be a potential hazard to a thing like a
mud, and therefore doing QA testing before putting it out on a production
system is a smart move.  Doing unit testing on a production system is asking
for trouble.  How many people (admins/arches) on muds have at some point in
their life changed code without doing an update and load to test it?  And how
many have written a piece of code that caused a major problem?

> > That, together with a fairly sound system to limit what code can be
> > retained forever as objects (e.g. rooms, until they are explicitly removed)
> > tends to do the trick.
> 
> You are suggesting to destroy all but certain objects before doing a
> statedump, here?  Sounds a bit impractical to me.

No, I am suggesting that alot of objects can be considered part of the stable
state of the mud, and therefore should never have to be destructed.  Once those
objects are no longer part of the stable state (e.g. with rooms, you redesigned
the area, and the room is no longer going to be accessible or has been replaced)
someone should explicitly destruct the object, so that it will no longer be part
of the stable state (and therefore will no longer be part of the statedump since
the object is gone).

	Kris

List config page:  http://list.imaginary.com/mailman/listinfo/dgd