[MUD-Dev] dispatching events

[Mark Gritter]

On Thu, Jul 22, 1999 at 01:02:23AM -0500, Greg Miller wrote:
> 
> I'm working on a lockless C&C game driver at the moment, and I'm
> wondering how others handle the dispatching of events. I see three
> approaches:
> 
> [1] Calling object/function pairs by name. This is simple, but it seems
> rather less flexible than other approaches.
> 
> [2] Subscriptions. In this case I'm referring to events that trigger
> calls to all subscribers as a single atomic unit. More flexible, but I
> can easily envision situations where events have to be restarted
> repeatedly if there are many subscribers.
> 
> [3] A combination of the two, using two stage events, where the first
> stage generates a list of pending object/function pair calls. This would
> allow each call to be handled atomically, but is far more complex.
> 
> I'm experimenting with #3 right now--anyone got any comments on the
> subject?

I think the difference is mainly how much inconsitency you're willing to
tolerate.  It doesn't seem to me that [3] preserves the semantics of [2].  
In particular, two events might appear in different orders to different 
objects.  This may not be a problem if your world allows this--- 
serializability is overrated. :)  (and can still be enforced at a higher level
in the cases which really need it.)

There are ways to a avoid pessimal behavior in [2].  For example, increase
an event's "priority" each time it fails.  (J C Lawrence suggested
something like this in the "lockless system -- foolproof?" thread last year.)

Another hybrid scheme is to break large subscriptions into atomic
subsubscriptions of smaller size, grouped by "closeness".  The hope is that
objects that interact with each other will see a consistent event model,
while avoiding contention.  The bookkeeping necessary for this may tend
to make it not worthwhile--- and there's little real gain in what semantics
you may assume.

Does [3] really have to be implemented at the driver level?  It seems
identical in implementation to [1], except for the introduction of 
"subscription" objects.

--
Mark Gritter <mgritter at cs.stanford.edu>
http://www-cs-students.stanford.edu/~mgritter/




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev