[DGD] Upgrade management

Gary gary at mups.co.uk
Sat Feb 25 18:50:50 CET 2017


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.

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

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.

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.

Regards,

Gary



More information about the DGD mailing list