[DGD]statedumping

[E. Harte]

On Wed, 10 May 2000, Kris Van Hees wrote:

> On Wed, May 10, 2000 at 04:20:03PM -0400, Stephen Schmidt wrote:
> > Ah, a slightly different question then: What does DGD do if the
> > swap file exceeds the maximum size? I don't know. I imagine it
> > does something that raises a problem for true perpetuality, but
> > what is it?
> 
> 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). :-)

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

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

Erwin.
-- 
Erwin Harte  -  Forever September, 2444 and counting  -  harte at xs4all.nl


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