[DGD] Re: Recursion in recompile(), is this correct?

[Bart van Leeuwen]

On Mon, 12 Jan 2004, Noah Gibbs wrote:

>   Yeah.  It's not actually so bad...  It's just a
> matter of making sure you've got strategically-placed
> catch() statements so that an error can be recovered
> from.  At least, that's been my experience.

Since all my calls to compile_object are centralized and caught and I have
an extesive mechanism in place for keeping track of what is currently being
compiled and what triggered the compile, this shouldn't be much of a
problem.


> > > Yep, call_outs, input of any kind... sounds like
> > lots of fun to me..
>
>   Yup.  There's an easy way to block call_outs, it
> turns out, in the Kernel Library resource manager.
> Ditto for input.  I don't think the input-blocking
> thing works for connections, so I actually have a
> separate "suspended" message that you get when you try
> to connect to the MUD while it's upgrading.  It tells
> you to try back in about ten seconds.  It doesn't take
> nearly a full ten seconds to rebuild, but I figure a
> conservative estimate is better :-)

Hmm. has anyone ever tried a setup where upgrades of 'children' of a
recompiled library are delayed untill the next time the child is
referenced? Is this possible to do at all? You'd need some way to deal
with objects that do not get referenced in the near future, but those
shouldn't be causing inconsistency problems either, and such a 'just in
time' approach would eliminate the need of blocking the entire mud for
doing such an upgrade.

>
>   But yeah, as Felix notes, make sure you have catch
> blocks in the right locations so that an error will
> cancel everything (or at least, cancel the operation
> that just had the error and not reschedule it) and
> restore call_outs and input and new connections.
>
>   I actually do this when doing my %datadump operation
> too...  Since I'm saving all the objects in the MUD, I
> have to keep people and critters from moving around
> and giving me an inconsistent state.  That would be
> yet *another* disadvantage of data files compared to
> state dumps, alas.  So for periodic backups, I
> recommend statedumps :-)

*choke*
hmm, yeah, you definitely want to use statedumps for that ;)

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