<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] C&C and Event Rescheduling --> <!--X-From-R13: Eunja Vnycraal <znynpunvNvanzr.pbz> --> <!--X-Date: Wed, 20 Aug 1997 14:12:28 +0000 --> <!--X-Message-Id: 33FAFB3C.167EB0E7#iname,com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199708152008.NAA18444#xsvr3,cup.hp.com --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] C&C and Event Rescheduling</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:malachai#iname,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="msg00692.html">Previous</a> | <a href="msg00694.html">Next</a> ] Thread: [ <a href="msg00610.html">Previous</a> | <a href="msg00753.html">Next</a> ] Index: [ <A HREF="author.html#00693">Author</A> | <A HREF="#00693">Date</A> | <A HREF="thread.html#00693">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] C&C and Event Rescheduling</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI> <LI><em>Subject</em>: Re: [MUD-Dev] C&C and Event Rescheduling</LI> <LI><em>From</em>: Shawn Halpenny <<A HREF="mailto:malachai#iname,com">malachai#iname,com</A>></LI> <LI><em>Date</em>: Wed, 20 Aug 1997 10:12:12 -0400</LI> <LI><em>Sender</em>: <A HREF="mailto:rsh#iname,com">rsh#iname,com</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> clawrenc#cup,hp.com wrote: > > Nothing ever originates from the DB. The DB has no way of ever > causing a new event to be logged. All events either source > externally (user commands and the like), or are the result of prior > events logging new events as part of their C&C closing stanza. > > 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> > > It also feels __really__ bad. I'm too buried right now to see all > the details of why (other than the fact that you've now tied your > DB design very tightly into your server and event model design). I've approached it in similar fashion. I think when I first looked at it, I'd thought that moving everything down into the DB would result in having to manage the same set of data I am managing now, only it would be spread out into each object, rather than neatly centralized in the executor. > >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. Yep, that's what I've got in mind right now, although I've one big working set that starts empty when the event begins processing, and through however many method calls on whichever objects grows larger until everyone returns and the entire set commits. Semantic difference--I'm making no distinction of working sets between method calls, though the end result is the same. > Unless you're talking about event synchronisation. That's a whole > different kettle of fish, and one I'm not very happy with at the > moment. I've long wanted to support something equivalent to the > ADA synchronise() API, where multiple threads (or in my case > events) could all ensure that they don't proceed until all the > other members have gotten to that point. Nope. Although, I've turned to thinking that since I currently stamp each event with the time (microsecond granularity) at which it is posted (no change upon rescheduling), I can only execute an event if there are no older events waiting. I think this will void the entire notion of priority, though, since it then becomes impossible for two events to be posted at the same time (provided that posting an event does not take under a microsecond, something I probably won't have to worry about). Unfortunately, this introduces a useless, semi-disguised blocking: Jane opening a door on one side of the world doesn't get executed until Bubba opening one on the other side is done first, even though there's no intersection between the working sets. A fix to that lies in what I'd touched on earlier about events originating from the same object are executed oldest to newest. What attracts me to this is that I can have method post any number of events while it's executing and have the results come out exactly as I expect, regardless of scheduling. Currently, it seems I should only allow a method to post a single event during its execution, and then chain them together, each spawning the next until everything is completed. If you use a sequence counter to ensure user commands are executed in the order given, is that same functionality available to all other events which must execute in proper sequence? If not, how do you determine who requires that functionality? And if it's not applicable in all cases, what of the user programmers who don't understand why their events aren't always happening in the order they've coded them? -- Shawn Halpenny "At any given time there is a 50% chance I've become discontinuous on the probability axis." - Me </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="00753" HREF="msg00753.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong> <ul compact><li><em>From:</em> clawrenc#cup,hp.com</li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00610" HREF="msg00610.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></STRONG> <UL><LI><EM>From:</EM> clawrenc#cup,hp.com</LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00692.html">Re: [MUD-Dev] Re: Character evolution</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00694.html">Re: [MUD-Dev] Looking for books...</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00610.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00753.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00693"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00693"><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>Re: [MUD-Dev] C&C and Event Rescheduling</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00690" HREF="msg00690.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Jeff Kesselman <a href="mailto:jeffk#tenetwork,com">jeffk#tenetwork,com</a>, Wed 20 Aug 1997, 05:16 GMT </LI> </ul> </ul> </ul> </ul> <LI><strong><A NAME="00613" HREF="msg00613.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Fri 15 Aug 1997, 22:32 GMT </LI> </ul> </ul> </ul> <LI><strong><A NAME="00563" HREF="msg00563.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 14 Aug 1997, 20:25 GMT <UL> <LI><strong><A NAME="00610" HREF="msg00610.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Fri 15 Aug 1997, 20:10 GMT <UL> <LI><strong><A NAME="00693" HREF="msg00693.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Wed 20 Aug 1997, 14:12 GMT <UL> <LI><strong><A NAME="00753" HREF="msg00753.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 27 Aug 1997, 01:21 GMT </LI> </UL> </LI> </UL> </LI> </UL> </LI> <LI><strong><A NAME="00602" HREF="msg00602.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Nathan Yospe <a href="mailto:yospe#hawaii,edu">yospe#hawaii,edu</a>, Fri 15 Aug 1997, 06:56 GMT <UL> <LI><strong><A NAME="00624" HREF="msg00624.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Adam Wiggins <a href="mailto:nightfall#user2,inficad.com">nightfall#user2,inficad.com</a>, Sat 16 Aug 1997, 20:49 GMT </LI> </UL> </LI> <LI><strong><A NAME="00618" HREF="msg00618.html">Re: [MUD-Dev] C&C and Event Rescheduling</A></strong>, Adam Wiggins <a href="mailto:nightfall#user1,inficad.com">nightfall#user1,inficad.com</a>, Sat 16 Aug 1997, 05:40 GMT </LI> </ul> </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>