<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: X Q Znjerapr <pynjNhaqre.rate.ftv.pbz> -->
<!--X-Date: Fri, 15 May 1998 13:44:24 -0700 -->
<!--X-Message-Id: 199805152044.NAA01884#under,engr.sgi.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199805132119.QAA25632@dfw-ix8.ix.netcom.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:claw#under,engr.sgi.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="msg00612.html">Previous</a>
| <a href="msg00615.html">Next</a>
]
Thread:
[ <a href="msg00556.html">Previous</a>
| <a href="msg00454.html">Next</a>
]
Index:
[ <A HREF="author.html#00613">Author</A>
| <A HREF="#00613">Date</A>
| <A HREF="thread.html#00613">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>: J C Lawrence <<A HREF="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</A>></LI>
<LI><em>Date</em>: Fri, 15 May 1998 13:44:13 -0700</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 Wed, 13 May 1998 17:20:31 -5
Jon A Lambert<jlsysinc#ix,netcom.com> wrote:
> 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:
>> 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.
Perhaps I should put a large red button on the chest of every mobile
with a "restart" label. Umm, perhaps that should be a "Start" button
with a happy Mick Jagger tune when pressed?
In essence that is how the mobile will be initially animated anyway.
<ponder>
Simpler:
Mobiles are animated by event chains.
It is possible to code events such that the probability of their
inability to execute is proximate to zero. It is definitely possible
eo ensure that an event is executable by an otherwise "happy
(logically sound etc) system.
Ergo. Just use a parallel watchdog event chain which periodically
checks up on the animation status of its ward mobile, and if missing,
reboots it.
Hurm.
SMMP -- Simple Monster^H^H^H^H^H^Hobile Monitoring Protocol.
Its not guaranteed, but it will work until your system gets *really*
ill. It would be fairly simple to provide a third level of
indirection with a register of monitor event chainsa long with a
check-monitors and restart-monitors feature for error recovery.
>> 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.
Yes.
> 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?
I don't *think* so. The only time this occurs for me is when the code
is physically unable to execute due to internal error or similar.
> 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.
"Yeah, if things break the system becomes unusably slow," vs "Yeah, if
things break almost everything just turns off like the power had been
pulled, but you can still do things."
>> 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?
All three. It hides the failures, reincarnates a polling loop under
the covers, and doesn't solve the problem. Its a bandaide, but at
least with the advantage that it can be a really cheap bandaide (you
can run the state check every 30 minutes as vs every 30 seconds).
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
On Wed, 13 May 1998 17:20:31 -5
Jon A Lambert<jlsysinc#ix,netcom.com> wrote:
> 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.
--
J C Lawrence Internet: claw#null,net
(Contractor) Internet: coder#ibm,net
---------(*) Internet: claw#under,engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00556" HREF="msg00556.html">[MUD-Dev] Re: atomic functions</A></STRONG>
<UL><LI><EM>From:</EM> "Jon A. Lambert" <jlsysinc#ix,netcom.com></LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00612.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00615.html">[MUD-Dev] Re: Is There a There in Cyberspace?</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00556.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00454.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00613"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00613"><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>
<ul compact>
<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><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>
<LI><strong><A NAME="00460" HREF="msg00460.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, 15:23 GMT
</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>
