[MUD-Dev] C&C and Event Rescheduling

[Shawn Halpenny]

clawrenc at 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