[DGD]Global Reset

[E. Harte]

On Mon, 11 Sep 2000, Stephen Schmidt wrote:

> On Mon, 11 Sep 2000, Malcolm Tester wrote:
> > But besides that,  you're going to have other problems as well, if
> > you use heart_beat() as the mechanism to track that.  I'm not a hard-core
> > DGD user, so I can say things based on what I've used/seen in LD/Amylaar 
> > and MudOS, but I assume the basics are the same. heart_beat() has a
> > very important function of determining who is "living" and who is not.
> 
> Just for clarification, they aren't the same; in fact they're
> quite different.
> 
> DGD has no heart_beat() function. None. It just has call_out().
> If you want a heart beat, you've got to code it in the mudlib.
> The 2.4.5 mudlib (which IIRC is what the original poster was
> using) handles it in the traditional way.

What is "the traditional way" according to you?  I'm confused.

>                                           Other DGD mudlibs
> don't. Melville, for instance, puts it into the auto object,
> so that every object can use heart_beat() if it wants to, not
> just living ones. In that case other mechanisms have to be
> used to determine what's living and what's not.

If you're implying here that the 2.4.5 DGD lib doesn't have the
heart_beat() functionality in the auto-object, you're wrong:

---- Quote from mud/2.4.5/dgd/lib/call_out.c ----
/*
 * NAME:        set_heart_beat()
 * DESCRIPTION: start or stop the heart_beat
 */
static int set_heart_beat(int flag)
{
[...]
----

>                                                 I believe
> that other DGD mudlibs don't have heart beat at all, and you
> have to invoke call_out() directly yourself, although I
> couldn't name any that are like that offhand.
> 
> > If you activate heart_beat() in every object on the game, you will in
> > effect call everything living.
> 
> Under 2.4.5, yes. Under Melville it would be -every- object.
> Under other libs it could be something else.

The 2.4.5 DGD lib does not have a direct relation between a running
heartbeat and an object being living(), it keeps track of these things
separately:

---- Quote from mud/2.4.5/dgd/lib/living.c ----
private int alive;              /* living flag */
[...]

/*
 * NAME:        _Q_alive()
 * DESCRIPTION: return the living status of this object
 */
nomask int _Q_alive()
{   
    return alive;
}

[...]
/*
 * NAME:        living()
 * DESCRIPTION: determine if an object is alive
 */
static int living(object obj)
{
    ARGCHECK(obj, living, 1);

    return obj->_Q_alive();
}
----

> > heart_beat() tends to be an expensive function to execute.
> 
> Depends on the mudlib. For 2.4.5, yes. For Melville, it depends
> on what you put into the heart_beat().  If you don't put anything
> in, then it runs as fast as any empty call_out() (or at least,
> nearly so; it does do some error trapping). If you write your
> own mudlib, it can be fast or slow depending on what you put
> in there.

I think your claim about 2.4.5 is again based on misremembering or
misinformation. :)

> However, for any mudlib with more than a few dozen objects,
> invoking the same function in all of them at the same time
> is going to be problematic. Especially so once they start
> swapping out and have to be swapped back in. It's much better
> to have each one handle its own updating, and stagger the
> cycles, so that the load is distributed over time, rather
> than having every object try to update at once. Keep all
> necessary centralized information in a (small!) daemon
> object, and have each object call into it to get the
> information it needs.

Yes.  That is probably the most practical solution, and similar to mine,
but like mine quite likely not what the original poster was hoping to
implement. :-)

Erwin.
-- 
Erwin Harte  -  Forever September, 2568 and counting  -  harte at xs4all.nl
[ 4:25pm  up 33 days, 20:56, 11 users,  load average: 0.03, 0.02, 0.00 ]


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