[MUD-Dev] C&C and Event Rescheduling

[Jon A. Lambert]

BTW thanks for the archives JCL! :)

> From: clawrenc at cup.hp.com
> >   at 01:27 PM, Shawn Halpenny <malachai at iname.com> said:
> 
<snip>
> That is a model question that I have slated to look into again.  It
> actually cuts very close to the core of the entire event model:
> 
>   Should the logging and storage of pending event data be localised
> into a central object or repository, or should pending events be
> bound to their owning objects?
> 

The latter resembles the pure event model which I alluded to in my
last post.  Essentially the dispatcher is dumb and merely passes
messages around to objects.  The biggest problem is solving 
transactional consistency if every method is an event or object
message.

> There are some efficiency and stability questions underneath this.
> 
> Currently I do everything centrally.  Objects have no idea that
> there are events pending for them, or that their internal code has
> been responsible for logging events for other objects.  This was a
> deliberate decision back when I decided (for reasons now largely
> forgotten but centered on keeping the division of larbour and OO
> design clean) that the DB should *NOT* be self-animating, but that
> the DB should essentially be dead, and animated by an external
> structure of events.  
>

Yes, but the objects in the DB are "primed" at some point via 
creation or load/reboot of server and the DB's objects sustain life
by issuing events as their events die.  I prefer this also.  

[snipped familiar model]
> 
> What I could do instead is move everything down into the DB.  As
> such the concept of the Dispatchor would largely remain, but the
> Executor would largely be lost.  Instead each individual object
> would become its own dispatchor or executor.  There would be some
> inevitable efficiency losses, but it could work.  
> 
> <shudder>

Exactly.

> >One could use a sort of "super" event that is responsible for the
> >execution of a series of sub-events, and successful commit of the
> >super would occur when all the subs themselves committed.
> >Unfortunately, the potential for involving a large(r) number of
> >objects in that super event could cause a lot of failed commits
> >until this super event drove the thing to single-threading.
> 
> This is essentially the concept of supporting nested transactions.
> its almost inevitable.  I do this implicitly by making every method
> call effectively a nested transaction.  The result is that each
> method call inherits the working set of its caller, and commits its
> working set back to its caller on return.  If it turns out that
> there is no parent (ie it is the method that started the event),
> then the working set tries to commit to the DB.
> 
> Hurm.
>

Perhaps there is another way?  Someone requested (Shawn?) that I
post an example of a mud language which handled transactions.
So here be it:

object Dragon class BigMutha {
	var fatigue_points;
	var location;
	method event Move(var direction) {
		if Dragonden.ExitStatus(direction) == OPEN {
			Dragonden.RemoveObj(this);
			Dragonden.GetExitLocation().AddObject(this);
			FatigueMe(5);
			EvaluateSituation(10);
		}
		else 
			SendOut("The Door is Closed");
			EvaluateSituation(10);
			throw #EVENTFAIL;
		}
	}
	method FatigueMe(var points) {
		fatigue_points = fatigue_points - points;
		if fatigue_points < 0 {
			fatigue_points = 0;
			SendOut("Your too tired to move");
		   	EvaluateSituation(10);
			throw #EVENTFAIL;
		}
	}
	method event EvaluateSituation() {
		...Insert some clever code here 
		which might at some point select...
		Move(20,"east");
	}
}
	
The important points are the different types of methods.  Event
methods form a logically consistent transaction and may call
any number of methods of any type.  Commit of the transaction
is done at the end of the event's method.  Also when 
EvaluateSituation() is called above a new event is logged and
it is not executed immediately.  The next statement is. 

Event methods have as their first implicit parameter a timing
value.  In the above case Move(20,"east") will occur in 20 tenths
of a second (I hope).

Comments?


JL