[DGD] Keeping track of clones

[Par Winzell]

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

Zell