[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

clawrenc at cup.hp.com wrote:
> 
> In <33D63D8C.167EB0E7 at iname.com>, on 07/23/97
>    at 09:53 PM, Shawn Halpenny <malachai at iname.com> said:

[ determining object has changed during event execution ]

> >Right now, my design is to just do a bitwise comparison just like
> >above, but I'm also thinking of something involving an object
> >checksum of sorts computed when an object is committed.
> 
> A simple approach (oustide of disk space) is to expand your object
> definition to also enclude a time stamp of the last change.  This can
> be a nanosecond clock or a time_t.  If different the objects fail C&C.
> If the same, *then* do the bit comparison when they're the same.

Yes.  While pondering this stuff yesterday I'd thought about a
counter that keeps track of the number of attribute-writes for that
object.  Should it have changed by the time the next commit comes
around, then do a comparison (actually, if the count is different,
isn't it safe to assume that _some_ attribute was changed, therefore
don't do a comparison at all?)

I'm still considering individual attribute comparisons, but still have some
cases to work out.

> >Do your
> >events keep track of the attributes they touch or is that handled
> >entirely by the DB?
> 
> This is currently in a mess.  Actually that's an understatement.  I'm
> partially dug into Arjuna to use it as a persistant store.  Part and
> parcel of this idea would be devolving MUD objects at the storage into
> individual objects, one each per attribute and method.  Its then a
> simple matter of flagging the references at runtime to resolve what
> bits got checked/changed ans what didn't.

I've taken a cursory look at Arjuna, but I'm not sure that I'm
comfortable with every object being stored in its own file (doesn't
that turn into a linear search for an object, given its ID?).  It
seems to be a well-designed piece of software, though.

Making each attribute and method into an object is interesting.  It would
certainly simplify C&C, since there's no longer a need for attribute
checking.  Have to look into that.

> >Is there a problem with a situation where a
> >single object with attributes touched by two events within the
> >duration of a third event using the same object could cause some
> >attributes touched by the third event to falsely pass the comparison?
> 
> Yes, but I don't consider this a problem:

[ example elided ]

> Logically interesting I'll admit, but not a problem that I can see.

True, not a problem and interesting as you say.  For some reason it
bothers me, though, but is probably something I could live with (and
wouldn't have to consider if I counted commits or attribute changes).

> >>   Re: #7.  Similarly I post messages (flags really) to all the members
> >> of the interested parties lists for all the objects that a
> >> successfully committed transaction modified.  The effect of those
> >> flags is that the next time those events traverse a block boundary
> >> (essentially any piece of code wrapped in {braces}, such as entering
> >> or leaving an IF, or WHILE etc), the flag gets checked and if TRUE,
> >> the event aborts to reschedule.
> 
> >I do much the same, using the exception mechanism of the internal
> >language.
> 
> I explicitly didn't put this in the language exceptions as once an
> event compleats and attempts C&C there' no language running to receive
> the exception.  A new event would have to be started to catch the
> exception...

But the event that is being killed and rescheduled is active when the
C&C fails in the case where other events have to be notified that an
object they were using has changed.  Those events get the exception. 
I'm not quite happy with this either...I think I can tie it to my
notification stuff below (which is similar to your flags above) and
make it simpler (and uniform) overall.

> >> Concern:
> >>
> >>   An event generated IO.  How do you handle when it reschedules?
> >> Think about things like SAY, TELL, LOOK, etc for example cases.
> 
> >As of yet, I don't.  In the last few weeks I've been doing the
> >"formal" design of the base systems (network, DB, event handling).
> 
> Handling IO is a pretty big part of any server design.

Yes, yes...I just haven't got to it yet.  I'm still working the DB
and event interactions into something generic enough that when I tie in the
I/O I hopefully won't have (many) problems.

> Consider:
> 
>   Player A types, "get axe".
> 
>   Event 1 runs the "get axe" code.
> 
>   Event 1 issues the IO, "You pick up the axe." back to the player.
> 
>   Player B picks up the axe.  This event sucessfully commits.
> 
>   Event 1 then tries to C&C, fails, reschedules, and pops back with
> "What axe?"
> 
>   Meanwhile the player A sees:
> 
>     > get axe
>     You pick up the axe.
>     B picks up the axe.
>     What axe?
>     > i
>     ...no axe...
> 
> >Handling commands where events that have to touch a number of objects
> >that have likely changed by the time the event is processed isn't
> >something I've worked on yet.  Therein lies the difficulty.
> 
> Its worth attention.

Yep.  Haven't got to it yet.  Current thinking:  output should be
queued and then displayed when the event successfully commits, or
displayed immediately when a condition necessary for a successful
commit fails (i.e.  someone already picked up the axe).

[ events implementing channel verbs ]

> >At the moment, I'm thinking along the lines
> >of the "tell" verb posting an event for each receiving player, rather
> >than a root object to handle it.
> 
> Largely there's no semantic difference.  The trick is to not have an
> event which is dependant on successfully iterating the entire player
> base (or any group object classification for that matter) within a
> single event.  If you do that it will rarely successfully C&C and the
> player objects change.
> 
> Another side effect of the same problem:
> 
>   How do you handle broadcasting state changes to other objects?

The following is my first take on this, since until this point I had only
said that there needs to be some way of notifying other objects of state
changes:

Post an event to call the notification method on each interested object.
Only a single instance of this method needs to be running at a time, since the
event will now handle further state changes by way of the C&C mechanism and
thus keep retrying the notification code until it completes.  So, the
event is only posted if the notification method that is called is not
already being executed (this is maintained by a bit in a bit field within
the object).

--
Shawn Halpenny

"You can't buy the necessities of life with cookies"
                                    - "Edward Scissorhands"