[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On 13 May 98, J C Lawrence wrote:
> On Wed, 6 May 98 22:59:33 MST 
> Chris Gray<cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:
> 
> > [J C Lawrence:] 
> 
> >> What if this event daisy chain didn't start from a user command,
> >> but was generated by a mobile attempting its normal business of
> >> wandering the land?  If the event chain dies with that failed event
> >> the mobile itself "dies" -- there are no more events to "animate"
> >> it.
> 
> > Why must it die? 
>
> There's some underlieing logic going on that mandates this: (I expect
> you know this already from the discussions on this area a little over
> a year ago).
> 
> Events are the ONLY things that are capable of logging new events.
> Translation: A successfully executed event is the only thing capable
> of causing another event to be executed in the future.
> 

Note that I handle this conceptually similar to you and will list 
the notable differences. 

> An object is "animated" because of an by an event chain.  Somewhere
> back when, there was an "original" event which started the ball
> rolling.  That event ran, compleated, and logged a new event.  That
> one ran compleated, and logged a new event.  And in this manner, ad
> infinitum thru time until the present, the events have daisy-chained,
> each one created by the one before, jerk-stepping the mobile thru
> virtual reality in seeming animation.  

In S&S, once an event is logged by an executing transaction, it 
becomes completely independent of it's parent event.  Thus failure
of the parent event has no control over the execution of the child 
event.  Placement of events for intentional chaining in mudcode is 
critical.

> 
> What would happen if one of those events utterly failed to compleat?
> The mobile would die.  Nothing would log a "new" event for that
> mobile; nothing would animate it.  There would be no executing events
> to log future events to keep the process of change going.  It would
> just sit there, utterly dead, until something _external_ came along
> and changed it.
>

Is this problematic with your intended handling of uncaught 
exceptions. In C&C it would appear your event chain would die, while 
in S&S the failed event would reschedule with the possibility of 
scheduling child events over and over.  Is there no happy medium 
here?  The only reason I happen to prefer it this way, is that it is  
immediately and visually apparent through my process list command.
It has nasty side-effects for server thrashing however.  I have been 
thinking of only rescheduling on uncaught LOCK_FAIL exceptions.  This 
would be similar to C&C's rescheduling on "Compare" failures.  Still 
it is not a complete solution, although a safer one.

> Yes, you could do multiple and parallel event chains as you discuss
> below.  But what happens if the "master" chain dies?  Do you have a
> watchman chain whose only purpose is to ensure that there is a valid
> running master chain?  What if the watchman dies?  
> 
> This is thorny problem -- solvable, but not elegant.
> 
> > From a naive point of view, you want it to stop digging the canal
> > because something prevented it from continuing. The digging event
> > chain doesn't have to be the only event chain that exists for the
> > NPC. It could have a normal chain, that, because it is currently
> > digging, doesn't do things like wandering away, but can still do
> > things like poses, simple interactions with PC's, etc. The question
> > then becomes that of how the main chain knows that the dig chain has
> > terminated.
> 

This particular task does not sound to me like an atomically 
consistent transaction because it is a task that can be at an analog 
state.  Thus the event chain should be breakable, through external 
state changes.  Upon breaking the chain an event should be logged to 
message Bubba indicating that his digging had been interrupted, yet 
NOT rolled back.  On an animated NPC an event should be logged to 
cause the NPC to make a decision on future activities, which may end 
up with the resumption of digging or starting some other chain of 
events (e.g. gathering wood ala Warcraft) or going to sleep and 
stopping to eat.  :)

> True.  I do this by keeping state variables in the mobile object
> (acutally they are activity masks and are thus used to limit possible
> simultaneous action).  Thus the digging chain, as you say, runs in
> parallel with the "main" chain.  The main chain keeps popping to life,
> checks for validity and mostly finds that its inapplicable due to the
> digging chain and goes back to sleep by logging a new future event.
>

I suppose it is possible for a main/timer event to check on "dead" 
objects on a regular basis and reanimated them.  Does this solve the 
problem or just hide failures in the application event model?
Or is this simply a reincarnation of the Diku-esque big polling loop?
     
 
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--

--
MUD-Dev: Advancing an unrealised future.