[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <199707251411.JAA01418 at dfw-ix2.ix.netcom.com>, on 07/25/97 
   at 09:29 AM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> From: clawrenc at cup.hp.com
>On further thought, the amount of object copies doesn't bother me to
>much as a performance issue.  Many well-optimized locking DBs do 
>this as a matter of integrity.  The wasted time and possible race
>conditions in event rescheduling vs. wasted time waiting on "a lock" 
>and possible deadlocks do bother me.  I can't really make an informed
> guess as to which is better.  Some heavy duty profiling is probably
>in order.   

This is unquestionable.  Wish I had either the time or the tools to do
such.

>>   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?   }

This is part and parcel of rolling the base implementation of base
types to individual objects whicha re then composited to form norma
MUD objects.  Thus a base object might hold the code to a method, or
to an attribute.  Real MUD objects are then assembled under the covers
from collections of these.

Once that's done its relatively easy to determine if anything accesses
a given attribute.  Does anything ask the DB to load it after the
inheritance tree for the object has been built?  If so, its been
referenced.  If dual copies exist, its been changed.

>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?   

Unreliable enough, especially given a typically high MUD transaction
transaction rate, that I don't trust it.  

>A performance judgment on CRC calculation
>vs. 2nd object  copy with memory/bitwise comparison.

A change counter seems cheaper.

>> 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 exactly what I do.  Diagrammed:

  Event Q starts execution. 
  Event Q modifies object X (Object Y is interested in changes 
    to X (this is an entry in X's C&C stanza)).
  Event Q logs an event R.
    Event Q is added to R's C&C stanza.
  Event Q attempts to C&C and succeeds.
  The changes to X are commited. 
  All IO is released.
  Q's C&C stanza is read (a list of items to process post C&C).
    Event R is sent to the Dispatchor to be logged as an 
      event to process.
    A new event S is similarly logged to send an "I-HAVE-CHANGED" 
      message to Y from X
  Q is flushed from the system.
  The next event starts execution.  

>This might require another special method/object language construct. 
>It would handle indirect state changes as long as the room container
>is the primary propagator.  And yes, even a temporary "neighborhood"
>object could be born from the commit and die at the end of it's state
>change method *boggle*

The problem is that state change messages should not be confiened to
rooms, or be sourced from rooms.  Consider the old case of the the
Great God GooGoo and his associated relics.  It didn't matter where in
the land a relic was activated, GGG knew.

Extemporaneously creating a neighborhood for the collection of objects
which need to be messages on the state change is an idea worth
thinking about tho, even if the implementation derives doen to just a
list or table.

>A global CHAT object could then spawn gobs of events during its cycle
>through the world.  

Which is what my channel object does now, if indirectly.  

Player object Q does a channel comm.  An event is logged sending the
IO to the channel comm object.  The channel comm object appends the IO
to its internal history buffer.  The channel object logs a new event
to its C&C stanza and C&C's.  The new event comes to execute almost
immediately, and picks the first entry from the list of interested
parties (people listening to the channel), and logs two events to
_it's_ C&C stanza.  The first event merely sends the IO to the first
interested party off the list.  It then adds a new event to its C&C
stanza, and C&C's.  That event sends the IO to the next interested
party etc.  This daisy-chain continues until the entire list is done.

For those processes where the order of IOs are significant, a sequence
value is added to the braodcast IO.  The receiving method on the
player object then spools them, and releases them only in sequence
order.

>> Okay, 50 players in a room all moving west is unlikely.  How about 50
>> players in or near a room, some moving out the various doors, some
>> coming back into the room having left, others picking up or dropping
>> various objects (changes to the contents lists), Every single event is
>> now compeating for the chance to get a single unmodified copy of that
>> room when it C&C's.  
>> 
>> Now that I've cast doom and gloom.  This need not be a huge problem. 
>> The fix is to change the manner in which you write
>> events/transactions.  The requirement is to split events into the
>> smallest, fastest executing,  logically consistant units you can.  The
>> idea is that by making the runtime of an individual event as short oas
>> possible the chance of collision by other events is minimised. 
>> Further, by making the runtime short, the probability is that what a
>> given event sequence contends with on its first step will not be
>> contended for on its next step.  eg:
>>

>You could go to a pure event model, where ALL method references are
>considered object messages which are dispatched as events.  I have
>doubts whether any sort of application transactional integrity could
>be easily achieved with this approach, unless there is a strong in
>language mechanism in place.   

<shriek!>  Could be done, yes.  Proving logical security etc is a
nightmare.  No thanks.  <run> 

>...ala StartTransaction-EndTransaction.
>This takes the implicit nature of persistence out of the language.
>Blech...IMO implicity==simplicity for the potential mudlib coder.

Precisely.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...