<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: "Xba O. Znzoreg" <wyflfvapNvk.argpbz.pbz> -->
<!--X-Date: Wed, 13 May 1998 14:20:19 -0700 -->
<!--X-Message-Id: 199805132119.QAA25632@dfw-ix8.ix.netcom.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 9805070559.8x8m@ami-cg.GraySage.Edmonton.AB.CA -->
<!--X-Reference: 199805131805.LAA09660#under,engr.sgi.com -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: atomic functions</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:jlsysinc#ix,netcom.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00555.html">Previous</a>
| <a href="msg00557.html">Next</a>
]
Thread:
[ <a href="msg00540.html">Previous</a>
| <a href="msg00613.html">Next</a>
]
Index:
[ <A HREF="author.html#00556">Author</A>
| <A HREF="#00556">Date</A>
| <A HREF="thread.html#00556">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: atomic functions</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: atomic functions </LI>
<LI><em>From</em>: "Jon A. Lambert" <<A HREF="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</A>></LI>
<LI><em>Date</em>: Wed, 13 May 1998 17:20:31 -5</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent -- Kanga.Nu version" <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On 13 May 98, J C Lawrence wrote:
> On Wed, 6 May 98 22:59:33 MST
> Chris Gray<cg#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#ix,netcom.com /*\--
--/*\ Mud Server Developer's Page <<A HREF="http://www.netcom.com/~jlsysinc">http://www.netcom.com/~jlsysinc</A>> /*\--
--/*\ "Everything that deceives may be said to enchant" - Plato /*\--
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00613" HREF="msg00613.html">[MUD-Dev] Re: atomic functions</A></strong>
<ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00453" HREF="msg00453.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> cg#ami-cg,GraySage.Edmonton.AB.CA (Chris Gray)</LI></UL></LI>
<LI><STRONG><A NAME="00540" HREF="msg00540.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> J C Lawrence <claw#under,engr.sgi.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00555.html">[MUD-Dev] Re: Some essays I've written lately</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00557.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00540.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00613.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00556"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00556"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>[MUD-Dev] Re: atomic functions</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00437" HREF="msg00437.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Wed 06 May 1998, 21:31 GMT
<UL>
<LI><strong><A NAME="00444" HREF="msg00444.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 06 May 1998, 22:29 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00453" HREF="msg00453.html">[MUD-Dev] Re: atomic functions</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Thu 07 May 1998, 06:02 GMT
<UL>
<LI><strong><A NAME="00540" HREF="msg00540.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 13 May 1998, 18:06 GMT
<UL>
<LI><strong><A NAME="00556" HREF="msg00556.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 13 May 1998, 21:20 GMT
<UL>
<LI><strong><A NAME="00613" HREF="msg00613.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Fri 15 May 1998, 20:44 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00454" HREF="msg00454.html">[MUD-Dev] Re: atomic functions</A></strong>,
Chris Gray <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Thu 07 May 1998, 06:03 GMT
</LI>
<LI><strong><A NAME="00455" HREF="msg00455.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Thu 07 May 1998, 12:35 GMT
<UL>
<LI><strong><A NAME="00541" HREF="msg00541.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Wed 13 May 1998, 18:09 GMT
</LI>
</UL>
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
