[DGD] Kernel library question

[bart at wotf.org]

On Wed, 22 Aug 2018 18:40:31 +0200, Felix A. Croes wrote

<snip>

> This is one of various problems with the idea of callout suspension.
> Callout suspension was one of my first exploratory steps towards a
> mudlib suitable for Hydra, which didn't pan out.  Eventually I came
> to the conclusion that when there is work to do before the next
> callout runs, you do it during the current task, come what may.

I ran into some issues with this on wotf, which inspired me to implement
suspending call_outs.

However, wotf does not rebuild all objects in a single task, rather, it does
an atomic recompile of critical components in a single task, and if that works
out, it does a recompile of the remaining objects, and allows those to fail if
they don't compile (and keep those that failed in the update queue so they can
easily be recompiled after fixing possible errors).

The 'critical' part is enough to give an admin access to the 'mud shell' so
they can run code or recompile things etc.

Anyway, recompiling the remaining objects happens with a chain of call_outs,
and while it is running, all other call_outs are suspended (intercepted when
they fire, and rescheduled).

Not suspending call_outs did result in new code calling outdated code (and the
other way around) every so often, which at times caused problems.

As everything gets tested on a dev instance first, objects not compiling is
rather exceptional, so while the risk of old code calling new code (or the
other way around) still exists when an object fails to recompile, this tends
to be more exceptional than a call_out firing and causing trouble while the
recompile is still running.

Anyway, I am curious what issues you ran into with call_out suspension beyond
the one mentioned (which imo should be solvable, without needing some
centralized administration that would cause lots of potential rollbacks for
hydra).

What I'm looking at for lpcdb (which currently uses the same approach as wotf,
ie the old lpmud style find/remove_call_out api, but this is problematic for
that codebase) is to use an lwo as proxy for the call_out handle, and pass
this lwo to the call_out handler in the auto object. That allows rescheduling
the call_out, informing the proxy object of the new handle, and hide that from
any code using the proxy call_out handle. This way i won't need to keep track
of the mapping between 'virtual' call_out handles and the ones used by DGD in
some shared (between call_outs) data structure.

While lpcdb does not run on hydra, at least not on the limited version (it
needs the closures extension, and unless I only have a small user database,
will easily outgrow the number of objects allowed in the limited version), I
wonder if this approach would work with hydra without causing excessive rollbacks.

Bart.

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


--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/