[DGD] Upgrade management

[Raymond Jennings]

On Sat, Feb 25, 2017 at 9:50 AM, Gary <gary at mups.co.uk> wrote:

> On 25/09/15 04:30, shentino at gmail.com (Raymond Jennings) wrote:
> > Using your advice I was able to rewrite my upgrade process.  Thanks!
> >
> > Basically it features building a list of anything that is new or changed
> in
> > the inheritance tree when an object is recompiled, and applies any
> patches
> > requested by those new inheritables or programs.
> >
> > In the meantime the mud is frozen while the object and its clones are
> > marked with call_touch and added to a queue.  Then the mud is released
> and
> > the background queue burns through the pending objects on a 0-callout,
> > which makes sure that the objects are all patched in a finite period of
> > time, but without stalling the mud.
> >
> > When an object is recompiled, objectd freezes the mud, and 0-callouts
> > itself to get the new program in place, and then issues the
> obj->upgrade()
> > call after queuing the patches.
> >
>
> Digging up an old post,
>
> I've been looking at different ways to add an upgrade() callback to my
> objectd and was thinking along similar lines to what you appear to have
> gone with i.e JIT upgrade clones via call_touch and a background
> callout-0 to avoid anything lingering too long without an upgrade.
>
> I couldn't however see a way to get a list of clones for a given master
> other than looping over objreg::next_link(obj); and checking for the "#"
> suffix which has the downside of causing everything to be swapped in as
> it's looped over.
>

See below.

So I assume your objectd is tracking the clones itself? What structure
> are you using to track the clones per master object?
>

I took a page out of Skotos's book, and thankfully the page in question has
already been discussed publicly on the list so I don't have an NDA to worry
about.

Two things:

1.  You can keep track of clones in a list for easy reference, or at least
in a set.

2.  A loop with find_object(path + "#" + i), where i goes from 0 to
status(ST_OTABSIZE), can find them all, and you can use find_object to get
a reference *to* an object without swapping the actual object itself into
memory.

Method 1 is doable by anything that hooks in as an ObjectD.  With a lot of
clones though, method 2 becomes more efficient.

And you can always use method 2 to repair or correct any discrepancies in
your tracking in method 1 or any other method.

I was considering the case where there might be a reasonably small
> number of master objects but perhaps a vast number of clones. That
> might mean going with a mapping of mappings (indexed in a way Zell once
> suggested [id>>8][id%0xFF]) to store the clones all contained within a
> mapping indexed by the master object id.
>

See above about using a find_object(path + "#" + i) loop.

e.g:
>
>   map[master_id][clone_id>>8][clone_id%0xFF] = clone_obj;
>
> I'm curious as to the structure you went with though and any pros/cons
> of that.
>

Since it's trivial to use a loop to find all the clones I never really
bothered.

The structure was just a straight one level mapping from clone to something
or other.  I don't remember exactly what I used (recently recovering from a
massive hardware failure) but I do remember doing exactly what Skotos
suggested.  If there are too many clones to fit in one mapping, I just
delete everything and set a flag saying "too many to count" and revert to
the find_object loop I mentioned.

Regards,
>
> Gary
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd