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

[Bart van Leeuwen]

On Mon, 12 Jan 2004, Felix A. Croes wrote:

> Bart van Leeuwen <bart at wotf.org> wrote:
>
> > On Sat, 10 Jan 2004, Noah Gibbs wrote:
> >
> > > --- Erwin Harte <harte at is-here.com> wrote:
> > > > Which is where the 'block_input' kfun might come in
> > > > handy. ;)
> > >
> > >   Yeah.  I do it during the recompile, I just don't do
> > > it 'til all of the upgraded() call_out statements are
> > > done.  I need to.
> >
> > I was thinking a bit about this and am wondering how safe this is.
> > Of course if you rely on everything on your mud being upgraded, you will
> > need some mechanism for upgrading everything before anything else happens
> > on the mud.
> >
> > Will it work to do this in call_outs and just block input untill you are
> > done?
> > I can imagine that this will still allow for other call_outs to run in
> > between your upgrade call_outs, and as a result, other threads can run
> > while you are doing your upgrade still.
> >
> > My take would be that you really need to do this all at once, and just
> > ensure you do not run out of ticks by properly using rlimits
> >
> > Also, I do not see what you get from splitting it up over multiple
> > call_outs, you are going to block the entire mud anyway, and imho it would
> > be more efficient to finish the task at hand as quickly as possible.
> >
> > What I am suggesting is to use unlimited ticks for a 'main loop' that goes
> > through all the objects that need to be upgraded, and use a limit only for
> > each individual upgrade.
>
> This works fine as long as all of your objects with programs can be held
> in memory together.  In some muds, that is not feasible.  In such a case,
> you have to break up the upgrading process in order to let DGD swap out
> objects between LPC threads.

Hmm, good point, hadn't thought of that.
>
> You do have to block callouts as well as input from users, in order to
> prevent interruptions.  These are both dangerous operations, since an
> error can effectively halt the mud without a way to restart it.  But it
> can be done.

Yep, call_outs, input of any kind... sounds like lots of fun to me.. Oh
well, somehow I had figured I needed a way to temporary block all activity
anyway, guess it will have to be made before I even consider automatic
upgrading of the entire tree as an option.

Thanks for the clarification.

Bart

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