[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

GJon A. Lambert wrote:
> 
> > From: clawrenc at cup.hp.com
> > Subject: [MUD-Dev]  C&C and Event Rescheduling
> >
> >   Re: #5.  How do you determine that the object has changed during the
> > execution of the event?  I do this by always keeping an original copy
> > of the object to compare to the copy current in the DB and then do a
> > bit-wise comparison of the two objects.  The original copy is the
> > second copy made above for a modification.
> >
> >   Aside: I'm actually getting *slightly* neater than this as the
> > current plan encludes only making a copy of the object
> > attribute/member which is changed, and then only comparing that at
> > C&C.
> 
> The burdens of attribute detection are difficult.  How does
> one detect the difference between:
> 
> ObjectA method ()
> {
>    x = ObjectB.attrX;      // a direct reference
>    y = ObjectB.GetattrY(); // an indirect reference through accessor
>                            // perhaps a derived attribute?
> }

If you always know the object that is originating the access (read OR
write) of the attribute, whether it is direct or through a function (or
pointer, reference, etc.) makes no difference.

> Another possibility is for the DB manager to push the requesting
> events unique handle onto an interested parties list along with a
> CRC.  Upon an attempt to commit, you compare the stored event handle's
> CRC to real objects CRC.  Problem: How reliable is CRC-32/64?
> Worst case: the 1 in 32 billion(?) burp causes an invalid pointer
> reference followed by a big thump.  On reboot and reload of DB
> the invalid object reference is ideally gracefully groked.
> Another issue:  A performance judgment on CRC calculation vs. 2nd object
> copy with memory/bitwise comparison.

A third method (and the one I'm leaning toward) is keeping track of
whether or not a write was done to an attribute in the object.  If
so, the object probably doesn't match (or it does match and what was
written was the same as what was there before) the original read-only
reference, so kill and reschedule everyone who was interested in that
attribute (or if only keeping track of whether or not any attribute was
written to in the object, kill and reschedule those interested at all in
the object):  the only comparison you do is the flag on the attribute (or
object).

> >
> > Concern:
> >
> >   An event generated IO.  How do you handle when it reschedules?
> > Think about things like SAY, TELL, LOOK, etc for example cases.
> >
> 
> You also mention somewhere below about how some objects undergoing
> a state change will propagate/generate events (likely asynchronously).
> I see these objects being very similar and/or handy with IO.
> Maybe it's possible for either the DB manager or the VM to post
> the object state change events to the event scheduler after the
> point of a successful transaction commit.

This is my thinking in a post that just went out.  Queue the output
that is generated, and only display it IFF the commit was successful.
Any output that should be seen if a commit fails is output immediately.

--
Shawn Halpenny

"At any given time there is a 50% chance I've become discontinuous
 on the probability axis."
                                            - Me