[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <33F369B7.41C67EA6 at iname.com>, on 08/14/97 
   at 01:27 PM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

>[ handling user commands event-drivenly ]

>> The summary we arrived at last time was that by default user
>> commands should be executed strictly sequentially.  This was to be
>> done via sequence number dependancies.  However, we also saw a use
>> in commands which were to be explicity executed in parrallel with
>> other user commands.  One of the primary uses for such was an
>> interrupt command which more or less said, "kill the entire command
>> queue NOW!".

>Yep.  The posts leading to this one sparked my thinking that if the
>events were posted by the same object, execute them sequentially:  a
>generalization of the above player-command case.  Is such a
>generalization necessary?  The above case could be implemented in the
>player object itself, queuing things and doling them out as
>appropriate, rather than in the event-handling systems where the
>generalization would be done.

That is a model question that I have slated to look into again.  It
actually cuts very close to the core of the entire event model:

  Should the logging and storage of pending event data be localised
into a central object or repository, or should pending events be bound
to their owning objects?

There are some efficiency and stability questions underneath this.

Currently I do everything centrally.  Objects have no idea that there
are events pending for them, or that their internal code has been
responsible for logging events for other objects.  This was a
deliberate decision back when I decided (for reasons now largely
forgotten but centered on keeping the division of larbour and OO
design clean) that the DB should *NOT* be self-animating, but that the
DB should essentially be dead, and animated by an external structure
of events.  

To view this another way, the current structure could be represented
as the DB being a being an inactive lump of dead clay on top of which
dance the unholy trinity of the Dispatchor, Executor, and EventPool
which poke and prod the DB, (re)writing things in it and reading them
back later.  The DB by itself does nothing.  It merely acts as a
repository of code and attributes for the events controlled and
generated by the unholy trio.  

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).

>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.

Hurm.

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.

I have various ways of doing this right now, none of which I think are
either respectible enough to relate here, or worth keeping.

--  
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...