[DGD] Re: Clones and very large arrays

[Robert Forshaw]

>From: Par Winzell <zell at skotos.net>
>>And Bart mentioned that it is a useful method of getting rid of 'stray 
>>clones'. Unfortunately I don't see how. If you have a 'stray clone' lying 
>>around, how are you going to spot it from within a gigantic datastructure?
>
>Again this is one of those things you don't fully understand until you have 
>had to administer a persistent game. Once you boot DGD into a game that 
>uses state dumps, you will never ever again cold start it. That means every 
>persistent resource (i.e. rooted in a persistent object) you create will 
>still be with you in the year 2350 unless you have, on th very first day of 
>your uptime, administrative code in place that keeps track of these 
>objects.
>
>If you have a guest programmer who just executes,
>
>   clone_object("/foo");
>
>without doing something with the return value, and you don't have code at a 
>low level that registers this clone somewhere, this clone is more or less 
>gone forever. It is never garbage collected (it is not a LWO) and nobody 
>has a pointer to it. The only way it can be found is by using 
>find_object(), and for that you have to know the path name.
>
>Once you realize what a potentially huge and dark haystack an eternal 
>uptime is, and how little of a safetynet there is unless you write one 
>yourself, you will see the reason why people here rail against the idea of 
>rewriting the kernel library from scratch. There should be a layer of code 
>in place on top of DGD and below your mudlib that has been tested by dozens 
>of people before you, with all the bugs ironed out, that you can rely on 
>with absolute certainty. From the perspective of the mudlib writer, such 
>administrative code should be considered more or less part of the driver. 
>This discipline is essential.

This still doesn't answer the question: how do you (or the 'safety net') 
identify these 'stray clones' for what they are, in order to pin them down? 
I (or the 'safety net') can not just go "Hey, there is clone#86423, that 
sure looks like a stray clone to me...".

Fortunately, I have in mind a MUD where 'guest coders' aren't going to 
happen, in fact, only administrators can do anything with code. That should 
eliminate some of the risk (yes I have gone with the datafile approach).

>>Also, as people left me with the impression that they don't often recall 
>>the entire list of clones (those who use linked lists), what kind of 
>>useful information are they deriving from it?
>
>It's there for the same reason you keep 10 gallons of water in your 
>basement for when the earthquake hits, yet you don't amble down there to 
>refill your glass during dinner.

Interesting metaphor, but I wasn't enlightened by it. All you are storing, 
essentially, is a big list of objects, and all that list reveals is the mere 
existence of those objects. It does not tell you what those objects are, 
where they came from, what they are doing. In order to find out you'd have 
to call a function in those objects, and I sure as hell am not going to have 
the lib (the 'safety net' if you like) constantly calling functions in all 
the objects as if to say 'Hey, what are you, what are you doing, you don't 
look like a genuine clone, you look like a stray, should you be destructed' 
etc. etc...

Perhaps this safety net thing could be explained a bit better? I'd 
appreciate that.

_________________________________________________________________
Stay in touch with absent friends - get MSN Messenger 
http://www.msn.co.uk/messenger

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