[DGD] Keeping track of clones

[Petter Nyström]

On Thu, 25 Aug 2005, Par Winzell wrote:

>> 1. Keeping a separate data structure, i.e. a mapping with program names 
>> mapped to (potentially very large) arrays of living clones of that program.
>> 
>> 2. Using the objects themselves as linked lists, i.e. letting the master 
>> object have an object pointer to the first clone and the first clone a 
>> pointer to the second clone, etc.. (Should also keep pointers to previous 
>> clones for easier manipulation of the list.)
>> 
>> 3. Not using any additional data at all, but instead use the find_object() 
>> kfun. Since I know how many objects that are loaded, I would loop through 
>> all possibilities looking up (for example) /foo/bar#1, /foo/bar#2, etc. 
>> with find_object(). I figure this could be really slow if I have many 
>> objects loaded, but then I don't think I would need this sort of list other 
>> than when upgrading code and I could live with some delay for doing that.
>
> I've used all three. For enumeration purposes the SkotOS mudlib uses a 
> combination of 1) and 3) (and switches between them) depending on the clone 
> count. For emergency maintenance purposes 2) works fine, but of course you 
> can only traverse such a list by swapping in every object, and so it's 
> pointlessly slow for any operation that only needs status() type metadata.

I am a little hazy on when exactly an object is swapped in. But from what 
you say I take it that doing and ob = find_object("/foo/bar#123") wouldn't 
swap that object in, if it was found? Only if I'd start calling functions 
in that object? Or only if I'd call functions that'd actually change its 
state? Or...?

Thanks,

Jimorie